Re: [PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching
forgot to review acpi update earlier ..
On 22-03-16, 02:53, Rafael J. Wysocki wrote:
> Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
> +++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
> @@ -458,6 +458,43 @@ static int acpi_cpufreq_target(struct cp
> return result;
> }
>
> +unsigned int acpi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + struct acpi_cpufreq_data *data = policy->driver_data;
> + struct acpi_processor_performance *perf;
> + struct cpufreq_frequency_table *entry;
> + unsigned int next_perf_state, next_freq, freq;
> +
> + /*
> + * Find the closest frequency above target_freq.
> + *
> + * The table is sorted in the reverse order with respect to the
> + * frequency and all of the entries are valid (see the initialization).
> + */
> + entry = data->freq_table;
> + do {
> + entry++;
> + freq = entry->frequency;
> + } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
Consider this table:
11000
1
9000
And a target-freq of 1.
Wouldn't you end up selecting 11000 ? Or did I misread it ?
> + entry--;
> + next_freq = entry->frequency;
> + next_perf_state = entry->driver_data;
> +
> + perf = to_perf_data(data);
> + if (perf->state == next_perf_state) {
> + if (unlikely(data->resume))
> + data->resume = 0;
> + else
> + return next_freq;
> + }
> +
> + data->cpu_freq_write(&perf->control_register,
> + perf->states[next_perf_state].control);
> + perf->state = next_perf_state;
> + return next_freq;
> +}
> +
> static unsigned long
> acpi_cpufreq_guess_freq(struct acpi_cpufreq_data *data, unsigned int cpu)
> {
> @@ -740,6 +777,9 @@ static int acpi_cpufreq_cpu_init(struct
> goto err_unreg;
> }
>
> + policy->fast_switch_possible = !acpi_pstate_strict &&
> + !(policy_is_shared(policy) && policy->shared_type !=
> CPUFREQ_SHARED_TYPE_ANY);
> +
> data->freq_table = kzalloc(sizeof(*data->freq_table) *
> (perf->state_count+1), GFP_KERNEL);
> if (!data->freq_table) {
> @@ -874,6 +914,7 @@ static struct freq_attr *acpi_cpufreq_at
> static struct cpufreq_driver acpi_cpufreq_driver = {
> .verify = cpufreq_generic_frequency_table_verify,
> .target_index = acpi_cpufreq_target,
> + .fast_switch= acpi_cpufreq_fast_switch,
> .bios_limit = acpi_processor_get_bios_limit,
> .init = acpi_cpufreq_cpu_init,
> .exit = acpi_cpufreq_cpu_exit,
--
viresh
Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote: > On 25 March 2016 at 15:09, Peter Chen wrote: > > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote: > >> Currently the Linux kernel does not provide any standard integration of > >> this > >> feature that integrates the USB subsystem with the system power regulation > >> provided by PMICs meaning that either vendors must add this in their > >> kernels > >> or USB gadget devices based on Linux (such as mobile phones) may not behave > >> as they should. Thus provide a standard framework for doing this in kernel. > >> > >> Now introduce one user with wm831x_power to support and test the usb > >> charger, > >> which is pending testing. Moreover there may be other potential users will > >> use > >> it in future. > >> > > > > I am afraid I still not find the user (udc driver) for this framework, I > > would > > like to see how udc driver block the enumeration until the charger detection > > has finished, or am I missing something? > > It is not for udc driver but for power users who want to negotiate > with USB subsystem. > Then, where is the code the test user to decide what kinds of USB charger (SDP, CDP, DCP) is connecting now? -- Best Regards, Peter Chen
Re: [PATCH v6 2/4] power: reset: add reboot mode driver
Hi Krzysztof :
On 2016年03月28日 14:34, Krzysztof Kozlowski wrote:
On 24.03.2016 17:03, Andy Yan wrote:
Hi Krzystof:
(...)
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+const char *cmd)
+{
+ const char *normal = "normal";
+ int magic = 0;
+ struct mode_info *info;
+
+ if (!cmd)
+ cmd = normal;
+
+ list_for_each_entry(info, &reboot->head, list) {
+ if (!strcmp(info->mode, cmd)) {
+ magic = info->magic;
+ break;
+ }
+ }
+
+ return magic;
In absence of 'normal' mode (it is not described as required property)
the magic will be '0'. It would be nice to document that in bindings.
Imagine someone forgets about this and will wonder why 0x0 is written
to his precious register on normal reboot...
If the magic value is '0', we won't touch the register, please see
reboot_mode_notify bellow.
Ah, indeed... so we cannot use value of '0' for magic (e.g. to clear any
existing value for normal reboot)?
It seems that the value '0' cannot be used.
It would be nice to document that 'mode-normal' has a special
(hard-coded) meaning.
+}
+
+static int reboot_mode_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ struct reboot_mode_driver *reboot;
+ int magic;
+
+ reboot = container_of(this, struct reboot_mode_driver,
reboot_notifier);
+ magic = get_reboot_mode_magic(reboot, cmd);
+ if (magic)
+ reboot->write(magic);
+
+ return NOTIFY_DONE;
+}
+
+int reboot_mode_register(struct device *dev, int (*write)(int))
+{
+ struct reboot_mode_driver *reboot;
+ struct mode_info *info;
+ struct property *prop;
+ size_t len = strlen(PREFIX);
+ int ret;
+
+ reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
+ if (!reboot)
+ return -ENOMEM;
+
+ reboot->write = write;
+ INIT_LIST_HEAD(&reboot->head);
+ for_each_property_of_node(dev->of_node, prop) {
+ if (len > strlen(prop->name) || strncmp(prop->name,
PREFIX, len))
+ continue;
New line please for readability.
Okay
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
Ditto.
Okay
+ strcpy(info->mode, prop->name + len);
Ehm, and how do you protect that name of mode is shorter than 32
characters?
How about info->mode = prop->name + len ?
I don't get your answer.
As fair as I read the code, the prop->name can be very long and you are
copying it from 5 character. If the name of the mode has bazillion
characters then again my question: how do you protect that it will fit
in 32 bytes of 'mode'?
What I mean is set info->mode as a pointer point to prop->name + len
struct mode_info {
char *mode;
..
.
}
info->mode = prop->name + len
+ if (of_property_read_u32(dev->of_node, prop->name,
&info->magic)) {
+ dev_err(dev, "reboot mode %s without magic
number\n",
+ info->mode);
+ devm_kfree(dev, info);
+ continue;
+ }
+ list_add_tail(&info->list, &reboot->head);
+ }
+ reboot->reboot_notifier.notifier_call = reboot_mode_notify;
+ ret = register_reboot_notifier(&reboot->reboot_notifier);
+ if (ret)
+ dev_err(dev, "can't register reboot notifier\n");
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(reboot_mode_register);
+
+MODULE_AUTHOR("Andy Yan
Documentation would be appreciated. Although it is local header but
you decoupled them and you are exporting the function.
I think I should remove the EXPORT_SYMBOL_GPL.
You need to export symbols which are located in modules. Is it located
in module?
Best regards,
Krzysztof
Re: [PATCH 03/11] mtd: nand_bbt: add new API definitions
On Fri, Mar 25, 2016 at 4:49 PM, Boris Brezillon wrote: > On Mon, 14 Mar 2016 02:47:56 + > Peter Pan wrote: > >> Add new API definitions for nand_bbt to replace old ones without >> any users. These API includes: >> struct nand_bbt_create(struct mtd_info *mtd); >> struct nand_bbt *nand_bbt_create(struct mtd_info *mtd, >> const struct nand_bbt_ops *ops, >> struct nand_chip_layout_info *info, >> unsigned int options, >> struct nand_bbt_descr *bbt_td, >> struct nand_bbt_descr *bbt_md); >> void nand_bbt_destroy(struct nand_bbt *bbt); >> int nand_bbt_markbad(struct nand_bbt *bbt, loff_t offs); >> int nand_bbt_isreserved(struct nand_bbt *bbt, loff_t offs); >> int nand_bbt_isbad(struct nand_bbt *bbt, loff_t offs); >> >> Signed-off-by: Brian Norris >> Signed-off-by: Peter Pan >> --- >> drivers/mtd/nand/nand_bbt.c | 113 >> +++ >> include/linux/mtd/nand_bbt.h | 11 + >> 2 files changed, 124 insertions(+) >> > >> >> +struct nand_bbt *nand_bbt_create(struct mtd_info *mtd, >> + const struct nand_bbt_ops *ops, >> + struct nand_chip_layout_info *info, > > Should be const struct nand_chip_layout_info *. Fix this in v4 Thanks, Peter Pan
[PATCH] stm class: correct masterID range in setting via sysfs
The type of masterID is defined as 'unsigned int', theoretically one
can set masterID with a number larger than 'INT_MAX' as long as
'stm_data::sw_end' is larger than 'INT_MAX'.
Also, 'stm_data::start' and 'stm_data::end' is initialized in respective
drivers which should be able to use any value less than 'UINT_MAX' for
their masterIDs, of course including those values larger than 'INT_MAX',
but the current policy is wrongly assuming that masterIDs would not be
larger than 'INT_MAX'. This patch just corrected that.
Signed-off-by: Chunyan Zhang
---
drivers/hwtracing/stm/policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 1db1896..ce3edfd 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -107,7 +107,7 @@ stp_policy_node_masters_store(struct config_item *item,
const char *page,
goto unlock;
/* must be within [sw_start..sw_end], which is an inclusive range */
- if (first > INT_MAX || last > INT_MAX || first > last ||
+ if (first > UINT_MAX || last > UINT_MAX || first > last ||
first < stm->data->sw_start ||
last > stm->data->sw_end) {
ret = -ERANGE;
--
1.9.1
Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT
On Fri, Mar 25, 2016 at 4:50 PM, Boris Brezillon wrote: > On Mon, 14 Mar 2016 02:47:53 + > Peter Pan wrote: > >> Sorry for send the v3 out late. I went through a busy time in the past >> two month. >> >> Currently nand_bbt.c is tied with struct nand_chip, and it makes other >> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why >> onenand has own bbt(onenand_bbt.c). >> >> Separate struct nand_chip from BBT code can make current BBT shareable. >> We create struct nand_bbt to take place of nand_chip in nand_bbt.c. >> Struct nand_bbt contains all the information BBT needed from outside and >> it should be embedded into NAND family chip struct (such as struct >> nand_chip). >> >> Below is mtd folder structure we want: >> drivers/mtd/nand/ >> drivers/mtd/nand/raw/ >> drivers/mtd/nand/spi/ >> drivers/mtd/nand/onenand/ >> drivers/mtd/nand/chips/ > > Hm, we should have a chips directory under each interface type, because > vendor specific handling is dependent on the NAND interface. > Otherwise, yes, that's the idea. Update this in v4 Thanks, Peter Pan
[PATCH 1/1] ARM: dts: kirkwood: add kirkwood-ds112.dtb to Makefile
Commit 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology
NAS devices") created the new file kirkwood-ds112.dts but did not
add it to the Makefile.
Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")
Signed-off-by: Heinrich Schuchardt
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b25621a..f8308db 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ds109.dtb \
kirkwood-ds110jv10.dtb \
kirkwood-ds111.dtb \
+ kirkwood-ds112.dtb \
kirkwood-ds209.dtb \
kirkwood-ds210.dtb \
kirkwood-ds212.dtb \
--
2.1.4
Re: [PATCH v6 2/4] power: reset: add reboot mode driver
On 28.03.2016 16:40, Andy Yan wrote:
> Hi Krzysztof :
>
> On 2016年03月28日 14:34, Krzysztof Kozlowski wrote:
>> On 24.03.2016 17:03, Andy Yan wrote:
>>> Hi Krzystof:
>> (...)
>>
> +static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
> +const char *cmd)
> +{
> + const char *normal = "normal";
> + int magic = 0;
> + struct mode_info *info;
> +
> + if (!cmd)
> + cmd = normal;
> +
> + list_for_each_entry(info, &reboot->head, list) {
> + if (!strcmp(info->mode, cmd)) {
> + magic = info->magic;
> + break;
> + }
> + }
> +
> + return magic;
In absence of 'normal' mode (it is not described as required property)
the magic will be '0'. It would be nice to document that in bindings.
Imagine someone forgets about this and will wonder why 0x0 is written
to his precious register on normal reboot...
>>> If the magic value is '0', we won't touch the register, please see
>>> reboot_mode_notify bellow.
>> Ah, indeed... so we cannot use value of '0' for magic (e.g. to clear any
>> existing value for normal reboot)?
>
> It seems that the value '0' cannot be used.
How about mentioning it in bindings documentation?
(...)
> + strcpy(info->mode, prop->name + len);
Ehm, and how do you protect that name of mode is shorter than 32
characters?
>>> How about info->mode = prop->name + len ?
>> I don't get your answer.
>> As fair as I read the code, the prop->name can be very long and you are
>> copying it from 5 character. If the name of the mode has bazillion
>> characters then again my question: how do you protect that it will fit
>> in 32 bytes of 'mode'?
>
> What I mean is set info->mode as a pointer point to prop->name + len
>
>struct mode_info {
> char *mode;
> ..
> .
>}
>
>info->mode = prop->name + len
Ahh, I get it. Then I guess you should also do of_node_get() and
of_node_put()... and use kstrdup_const(). Looks good but I am not
familiar with overlays and life-cycle of OF nodes (documentation for the
life-cycle is a todo list item: Documentation/devicetree/todo.txt).
Best regards,
Krzysztof
Re: [PATCH 02/11] mtd: nand_bbt: introduce BBT related data structure
Hi Boris,
Firstly, thanks a lot for taking time to review my patches.
On Fri, Mar 25, 2016 at 4:35 PM, Boris Brezillon
wrote:
> Hi Peter,
>
> On Mon, 14 Mar 2016 02:47:55 +
> Peter Pan wrote:
>
>> From: Brian Norris
>>
>> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
>> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
>> onenand has own bbt(onenand_bbt.c).
>>
>> Separate struct nand_chip from BBT code can make current BBT shareable.
>> We create struct nand_bbt to take place of nand_chip in nand_bbt.c
>>
>> Below is mtd folder structure we want:
>> drivers/mtd/nand/
>> drivers/mtd/nand/raw/
>> drivers/mtd/nand/spi/
>> drivers/mtd/nand/onenand/
>> drivers/mtd/nand/chips/
>>
>> Of course, nand_bbt.c should be part of .
>>
>> We put every chip layout related information BBT needed into struct
>> nand_chip_layout_info.
>> @numchips: number of physical chips, required for NAND_BBT_PERCHIP
>> @chipsize: the size of one chip for multichip arrays
>> @chip_shift:number of address bits in one chip
>> @bbt_erase_shift: number of address bits in a bbt entry
>> @page_shift:number of address bits in a page
>>
>> We defined a struct nand_bbt_ops for BBT ops. Struct
>> @is_bad_bbm:check if a block is factory bad block
>> @erase: erase block bypassing resvered checks
>>
>> Struct nand_bbt includes all BBT information:
>> @mtd: pointer to MTD device structure
>> @bbt_options: bad block specific options. All options used
>> here must come from nand_bbt.h.
>> @bbt_ops: struct nand_bbt_ops pointer.
>> @info: struct nand_chip_layout_info pointer.
>> @bbt_td:bad block table descriptor for flash lookup.
>> @bbt_md:bad block table mirror descriptor
>> @bbt: bad block table pointer
>>
>> Signed-off-by: Brian Norris
>> [Peter: 1. correct comment style
>> 2. introduce struct nand_bbt_ops and nand_chip_layout_info]
>> Signed-off-by: Peter Pan
>> ---
>> include/linux/mtd/nand_bbt.h | 67
>>
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/include/linux/mtd/nand_bbt.h b/include/linux/mtd/nand_bbt.h
>> index 5a65230..cfb22c8 100644
>> --- a/include/linux/mtd/nand_bbt.h
>> +++ b/include/linux/mtd/nand_bbt.h
>> @@ -18,6 +18,8 @@
>> #ifndef __LINUX_MTD_NAND_BBT_H
>> #define __LINUX_MTD_NAND_BBT_H
>>
>> +struct mtd_info;
>> +
>> /* The maximum number of NAND chips in an array */
>> #define NAND_MAX_CHIPS 8
>>
>> @@ -115,4 +117,69 @@ struct nand_bbt_descr {
>> /* The maximum number of blocks to scan for a bbt */
>> #define NAND_BBT_SCAN_MAXBLOCKS 4
>>
>> +struct nand_bbt;
>> +
>> +/**
>> + * struct nand_bbt_ops - bad block table operations
>> + * @is_bad_bbm: check if a block is factory bad block
>> + * @erase: erase block bypassing resvered checks
>> + */
>> +struct nand_bbt_ops {
>> + /*
>> + * This is important to abstract out of nand_bbt.c and provide
>> + * separately in nand_base.c and spi-nand-base.c -- it's sort of
>> + * duplicated in nand_block_bad() (nand_base) and
>> + * scan_block_fast() (nand_bbt) right now
>> + *
>> + * Note that this also means nand_chip.badblock_pattern should
>> + * be removed from nand_bbt.c
>> + */
>> + int (*is_bad_bbm)(struct mtd_info *mtd, loff_t ofs);
>> +
>> + /* Erase a block, bypassing reserved checks */
>> + int (*erase)(struct mtd_info *mtd, loff_t ofs);
>> +};
>> +
>> +/**
>> + * struct nand_chip_layout_info - strucure contains all chip layout
>> + * information that BBT needed.
>> + * @numchips:number of physical chips, required for NAND_BBT_PERCHIP
>> + * @chipsize:the size of one chip for multichip arrays
>> + * @chip_shift: number of address bits in one chip
>> + * @bbt_erase_shift: number of address bits in a bbt entry
>> + * @page_shift: number of address bits in a page
>> + */
>> +struct nand_chip_layout_info {
>
> I know I'm the one who suggested this name, but NAND datasheet seems to
> call it "memory organization", so maybe we should rename this struct
> nand_memory_organization.
Fix this in v4
>
>> + int numchips;
>
> I would rename it numdies, or ndies. numchips implies you're having
> several chips, which is not the case.
Fix this in v4
>
>> + u64 chipsize;
>
> Ditto, s/chipsize/diesize/
Fix this in v4
>
>> + int chip_shift;
>
> Ditto.
Fix this in v4
>
>> + int bbt_erase_shift;
>
> Hm, this is not related to the memory organization. I'd prefer moving
> this one directly in
Yes, I also realize bbt_erase_shift is not proper. How about just rename it
to erase_block_shift or block_shift ?
>
>> + int page_shift;
>> +};
>
> The structure should probably contain other info like (oob size, pages
> per block, blocks per die, ...)
> I know
Re: [PATCH] arm: dts: mt2701: Add clock controller device nodes
Hi James, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.6-rc1 next-20160327] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/James-Liao/arm-dts-mt2701-Add-clock-controller-device-nodes/20160328-133113 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next config: arm-multi_v7_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): In file included from arch/arm/boot/dts/mt2701-evb.dts:16:0: >> arch/arm/boot/dts/mt2701.dtsi:15:42: fatal error: >> dt-bindings/clock/mt2701-clk.h: No such file or directory #include ^ compilation terminated. vim +15 arch/arm/boot/dts/mt2701.dtsi 9 * This program is distributed in the hope that it will be useful, 10 * but WITHOUT ANY WARRANTY; without even the implied warranty of 11 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 12 * GNU General Public License for more details. 13 */ 14 > 15 #include 16 #include 17 #include 18 #include "skeleton64.dtsi" --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH 05/11] mtd: nand: use new BBT API instead of old ones
On Fri, Mar 25, 2016 at 4:51 PM, Boris Brezillon
wrote:
> On Mon, 14 Mar 2016 02:47:58 +
> Peter Pan wrote:
>
>> Use new BBT APIs (nand_bbt_*()) in NAND. Keep old APIs (nand_*_bbt())
>> exist temporarily.
>>
>> Signed-off-by: Brian Norris
>> Signed-off-by: Peter Pan
>> ---
>> drivers/mtd/nand/docg4.c | 7 +-
>> drivers/mtd/nand/nand_base.c | 151
>> ---
>> include/linux/mtd/nand.h | 15 -
>> 3 files changed, 160 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
>> index b6facac..6f0e3b9 100644
>> --- a/drivers/mtd/nand/nand_base.c
>> +++ b/drivers/mtd/nand/nand_base.c
>
> [...]
>
>> +static int nand_default_bbt(struct mtd_info *mtd)
>> +{
>> + struct nand_chip *chip = mtd_to_nand(mtd);
>> + struct nand_bbt *nand_bbt = NULL;
>> + struct nand_chip_layout_info *info =
>> + kzalloc(sizeof(struct nand_chip_layout_info), GFP_KERNEL);
>
> No, this should be directly embedded in nand_chip, and should replace
> the numchips/chipsize/... fields declared in there.
As I said in patch 2, I keep it like this temporarily. Will embedded it in
struct nand_chip later.
Thanks,
Peter Pan
Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT
Hi Ezequiel, Sorry for reply your mail late. And thaks a lot for reviewing it. On Thu, Mar 24, 2016 at 4:57 AM, Ezequiel Garcia wrote: > Hello, > > On 13 March 2016 at 23:47, Peter Pan wrote: >> Sorry for send the v3 out late. I went through a busy time in the past >> two month. >> >> Currently nand_bbt.c is tied with struct nand_chip, and it makes other >> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why >> onenand has own bbt(onenand_bbt.c). >> >> Separate struct nand_chip from BBT code can make current BBT shareable. >> We create struct nand_bbt to take place of nand_chip in nand_bbt.c. >> Struct nand_bbt contains all the information BBT needed from outside and >> it should be embedded into NAND family chip struct (such as struct >> nand_chip). >> >> Below is mtd folder structure we want: >> drivers/mtd/nand/ >> drivers/mtd/nand/raw/ >> drivers/mtd/nand/spi/ >> drivers/mtd/nand/onenand/ >> drivers/mtd/nand/chips/ >> > > You mention this structure, but nothing in the current patchset is actually > enforcing it. This is more the future direction we are going. Yes, this is what we want. > >> Most of the patch is borrowed from Brian Norris >> . >> http://git.infradead.org/users/norris/linux-mtd.git/shortlog/refs/heads/nand-bbt >> I decided the authorship of each patch by contribution. Please let me know if >> there is something unproper. >> Based on Brian's suggestion and Boris's comments, I make 11 independent >> patches. Previous patch is http://patchwork.ozlabs.org/patch/492066/ >> After discussion with Boris and Ezequiel, I realized above structure is >> better, >> so I drop the patch to move nand_bbt.c to mtd folder. >> > > I have reviewed this patchset, and it looks mostly good to me. I can > spot trivial style comments, or comments related to the commit logs, or the > way commits are splitted. > > Boris will probably have more insightful comments to make. > > However, before starting my silly bikeshedding I'd like to know if we all > agree with the patchset's overall scheme. > > It would be good to finally move forward with this, to take mt29f out > of staging and also support other SPI NAND vendors. Yes. We plan to move mt29f_spi_nand out from staging. But because mt29f_spi_nand is under raw/parallel NAND framework, it mismatch the stucture we want. Rewite it under SPI NAND framework may be a better choice, right? Actually I'm working on this now. Thanks, Peter Pan
[PATCH] driver core: fix race between creating/querying glue dir and its cleanup
The global mutex of 'gdp_mutex' is used to serialize creating/querying
glue dir and its cleanup. Turns out it isn't a perfect way because
part(kobj_kset_leave()) of the actual cleanup action() is done inside
the release handler of the glue dir kobject. That means gdp_mutex has
to be held before releasing the last reference count of the glue dir
kobject.
This patch moves glue dir's cleanup after kobject_del() in device_del()
for avoiding the race.
Cc: Yijing Wang
Reported-by: Chandra Sekhar Lingutla
Signed-off-by: Ming Lei
---
drivers/base/core.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0a8bdad..3f2e1f8 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -836,11 +836,31 @@ static struct kobject *get_device_parent(struct device
*dev,
return NULL;
}
+static inline bool live_in_glue_dir(struct kobject *kobj,
+ struct device *dev)
+{
+ if (!kobj || !dev->class ||
+ kobj->kset != &dev->class->p->glue_dirs)
+ return true;
+ return false;
+}
+
+static inline struct kobject *get_glue_dir(struct device *dev)
+{
+ if (live_in_glue_dir(&dev->kobj, dev))
+ return dev->kobj.parent;
+ return NULL;
+}
+
+/*
+ * make sure cleaning up dir as the last step, we need to make
+ * sure .release handler of kobject is run with holding the
+ * global lock
+ */
static void cleanup_glue_dir(struct device *dev, struct kobject *glue_dir)
{
/* see if we live in a "glue" directory */
- if (!glue_dir || !dev->class ||
- glue_dir->kset != &dev->class->p->glue_dirs)
+ if (!live_in_glue_dir(glue_dir, dev))
return;
mutex_lock(&gdp_mutex);
@@ -848,11 +868,6 @@ static void cleanup_glue_dir(struct device *dev, struct
kobject *glue_dir)
mutex_unlock(&gdp_mutex);
}
-static void cleanup_device_parent(struct device *dev)
-{
- cleanup_glue_dir(dev, dev->kobj.parent);
-}
-
static int device_add_class_symlinks(struct device *dev)
{
struct device_node *of_node = dev_of_node(dev);
@@ -1028,6 +1043,7 @@ int device_add(struct device *dev)
struct kobject *kobj;
struct class_interface *class_intf;
int error = -EINVAL;
+ struct kobject *glue_dir = NULL;
dev = get_device(dev);
if (!dev)
@@ -1072,8 +1088,10 @@ int device_add(struct device *dev)
/* first, register with generic layer. */
/* we require the name to be set before, and pass NULL */
error = kobject_add(&dev->kobj, dev->kobj.parent, NULL);
- if (error)
+ if (error) {
+ glue_dir = get_glue_dir(dev);
goto Error;
+ }
/* notify platform of device entry */
if (platform_notify)
@@ -1154,9 +1172,10 @@ done:
device_remove_file(dev, &dev_attr_uevent);
attrError:
kobject_uevent(&dev->kobj, KOBJ_REMOVE);
+ glue_dir = get_glue_dir(dev);
kobject_del(&dev->kobj);
Error:
- cleanup_device_parent(dev);
+ cleanup_glue_dir(dev, glue_dir);
put_device(parent);
name_error:
kfree(dev->p);
@@ -1232,6 +1251,7 @@ EXPORT_SYMBOL_GPL(put_device);
void device_del(struct device *dev)
{
struct device *parent = dev->parent;
+ struct kobject *glue_dir = NULL;
struct class_interface *class_intf;
/* Notify clients of device removal. This call must come
@@ -1276,8 +1296,9 @@ void device_del(struct device *dev)
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_REMOVED_DEVICE, dev);
kobject_uevent(&dev->kobj, KOBJ_REMOVE);
- cleanup_device_parent(dev);
+ glue_dir = get_glue_dir(dev);
kobject_del(&dev->kobj);
+ cleanup_glue_dir(dev, glue_dir);
put_device(parent);
}
EXPORT_SYMBOL_GPL(device_del);
--
1.9.1
Re: [PATCH 3/4] drivers/bus: make simple-pm-bus.c explicitly non-modular
Hi Paul,
On Sun, Mar 27, 2016 at 11:10 PM, Paul Gortmaker
wrote:
> The Kconfig currently controlling compilation of this code is:
>
> config SIMPLE_PM_BUS
> bool "Simple Power-Managed Bus Driver"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
>
> We explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
Be prepared for the fallout. There are test farms running bind/unbind cycles
on random drivers.
> Since module_init translates to device_initcall in the non-modular
> case, the init ordering remains unchanged with this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Geert Uytterhoeven
> Cc: Kevin Hilman
> Cc: Simon Horman
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Paul Gortmaker
NAK.
IIRC, I did test unbind.
The real and productive fix is to change "bool" to "tristate" in Kconfig.
All of these "make ... explicitly non-modular" may have to be reverted again
when our kernels become too big to boot.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
Hi, Yoshihiro Shimoda writes: >> > ps: there might be bugs there, but it's a holiday and I really shouldn't >> > be spending time on this right now ;-) >> >> I'm also off on holiday now until Sunday 10th April... yay :-) >> > >> > Anyway, have fun testing. Let me know if it doesn't work. >> >> I only have access to STi platforms which were broken by this change. >> Not any of the platforms which rely on the functionality which >> was introduced (although I can't see any reason why your patch wouldn't >> work). >> >> Maybe Yoshihiro (on CC) could test this on the Renesas platforms and confirm? > > Thank you for sending the email to me on CC. > > I tested Felipe's patch on Renesas platfroms (R-Car Gen2 and Gen3) and > I fixed the patch like the following. > > However, my fixes patch might need to clean the code up more. > > Changes from Felipe's patch: > - Change function names of xhci_rcar_init_quirk() to xhci_rcar_setup_quirk() I'm not sure renaming that function fits on the same patch ;-) Sounds like it should be a separate patch altogether. I'll work on this tomorrow if it's okay for you guys to test on your respective platforms :-) -- balbi signature.asc Description: PGP signature
Re: [PATCH 28/31] iio: gyro: use parity32 in adxrs450.c
On 27/03/16 08:42, zhaoxiu.zeng wrote: > From: Zeng Zhaoxiu > > Signed-off-by: Zeng Zhaoxiu Interesting. Whilst obviously correct I wonder if this obscures the intent of the code a little. Lars, what do you think? Jonathan > --- > drivers/iio/gyro/adxrs450.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/iio/gyro/adxrs450.c b/drivers/iio/gyro/adxrs450.c > index a330d42..f1f19fc20 100644 > --- a/drivers/iio/gyro/adxrs450.c > +++ b/drivers/iio/gyro/adxrs450.c > @@ -108,9 +108,7 @@ static int adxrs450_spi_read_reg_16(struct iio_dev > *indio_dev, > > mutex_lock(&st->buf_lock); > tx = ADXRS450_READ_DATA | (reg_address << 17); > - > - if (!(hweight32(tx) & 1)) > - tx |= ADXRS450_P; > + tx |= !parity32(tx) * ADXRS450_P; > > st->tx = cpu_to_be32(tx); > ret = spi_sync_transfer(st->us, xfers, ARRAY_SIZE(xfers)); > @@ -144,9 +142,7 @@ static int adxrs450_spi_write_reg_16(struct iio_dev > *indio_dev, > > mutex_lock(&st->buf_lock); > tx = ADXRS450_WRITE_DATA | (reg_address << 17) | (val << 1); > - > - if (!(hweight32(tx) & 1)) > - tx |= ADXRS450_P; > + tx |= !parity32(tx) * ADXRS450_P; > > st->tx = cpu_to_be32(tx); > ret = spi_write(st->us, &st->tx, sizeof(st->tx)); >
Re: [PATCH] staging: iio: convert bare unsigned usage to unsigned int
On 26/03/16 19:58, Joe Perches wrote: > On Sat, 2016-03-26 at 12:50 -0700, Alison Schofield wrote: >> Use kernel preferred unsigned int declaration style. >> >> Patch created using: >> git ls-files drivers/staging/iio | \ >> xargs ./scripts/checkpatch.pl -f --fix-inplace --types=unspecified_int >> >> Hand edits restored columns in structure definitions. > > This all seems reasonable and it's good you redid the columns. > checkpatch isn't smart for that. Agreed. Nice patch. Applied to the togreg branch of iio.git, initially pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 1/1] ARM: dts: kirkwood: add kirkwood-nsa320.dtb to Makefile
Commit be3d7d023b87 ("ARM: kirkwood: Add DTS file for NSA320")
created the new file kirkwood-nsa320.dts but did not
add it to the Makefile.
Fixes: be3d7d023b87 ("ARM: kirkwood: Add DTS file for NSA320")
Signed-off-by: Heinrich Schuchardt
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f8308db..e75a340 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -215,6 +215,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ns2mini.dtb \
kirkwood-nsa310.dtb \
kirkwood-nsa310a.dtb \
+ kirkwood-nsa320.dtb \
kirkwood-nsa325.dtb \
kirkwood-openblocks_a6.dtb \
kirkwood-openblocks_a7.dtb \
--
2.1.4
Re: [PATCH 6/8] iio: adc: Fix at91-sama5d2_adc dependencies
On 25/03/16 22:40, Richard Weinberger wrote:
> Not all archs have io memory.
>
> Fixes the following build error:
> ERROR: "devm_ioremap_resource" [drivers/iio/adc/at91-sama5d2_adc.ko]
> undefined!
>
> Cc: Jonathan Cameron
> Cc: Hartmut Knaack
> Cc: Lars-Peter Clausen
> Cc: Peter Meerwald
> Cc: Ludovic Desroches
> Fixes: b9cd7a25 ("MAINTAINERS: add entry for Atmel SAMA5D2 ADC driver")
> Signed-off-by: Richard Weinberger
Hi Richard,
I already have a patch queued up covering this, it just hit at exactly the wrong
moment compared to the merge window so hasn't made it upstream yet.
Thanks,
Jonathan
> ---
> drivers/iio/adc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index af4aea7..31fa2e7 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -133,6 +133,7 @@ config AT91_ADC
>
> config AT91_SAMA5D2_ADC
> tristate "Atmel AT91 SAMA5D2 ADC"
> + depends on HAS_IOMEM
> depends on ARCH_AT91 || COMPILE_TEST
> help
> Say yes here to build support for Atmel SAMA5D2 ADC which is
>
Re: [PATCH] iio: adc: Fix build error of missing devm_ioremap_resource on UM
On 05/03/16 18:49, Jonathan Cameron wrote: > On 04/03/16 01:05, Krzysztof Kozlowski wrote: >> The devres.o gets linked if HAS_IOMEM is present so on ARCH=um >> allyesconfig (COMPILE_TEST) failed with: >> >> drivers/built-in.o: In function `at91_adc_probe': >> at91-sama5d2_adc.c:(.text+0x48f548): undefined reference to >> `devm_ioremap_resource' >> >> Signed-off-by: Krzysztof Kozlowski > Applied to the togreg branch of iio.git - initially pushed out as testing for > the autobuilders to play with it. I may switch this over to a fixes branch > and send it on post merge window (if the merge window starts before my next > pull request). This did indeed miss, so I'll pull it across to the fixes branch once the merge window closes. Jonathan > > Jonathan >> --- >> drivers/iio/adc/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig >> index af4aea7b20f9..82c718c515a0 100644 >> --- a/drivers/iio/adc/Kconfig >> +++ b/drivers/iio/adc/Kconfig >> @@ -134,6 +134,7 @@ config AT91_ADC >> config AT91_SAMA5D2_ADC >> tristate "Atmel AT91 SAMA5D2 ADC" >> depends on ARCH_AT91 || COMPILE_TEST >> +depends on HAS_IOMEM >> help >>Say yes here to build support for Atmel SAMA5D2 ADC which is >>available on SAMA5D2 SoC family. >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again
Hi Jonsoo,
On Mon, Mar 28, 2016 at 7:26 AM, wrote:
> From: Joonsoo Kim
>
> Initial attemp to remove BAD_ALIEN_MAGIC is once reverted by
> 'commit edcad2509550 ("Revert "slab: remove BAD_ALIEN_MAGIC"")'
> because it causes a problem on m68k which has many node
> but !CONFIG_NUMA. In this case, although alien cache isn't used
> at all but to cope with some initialization path, garbage value
> is used and that is BAD_ALIEN_MAGIC. Now, this patch set
> use_alien_caches to 0 when !CONFIG_NUMA, there is no initialization
> path problem so we don't need BAD_ALIEN_MAGIC at all. So remove it.
>
> Signed-off-by: Joonsoo Kim
I gave this a try on m68k/ARAnyM, and it didn't crash, unlike the previous
version that was reverted, so
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 1/6] hwmon: (fam15h_power) Add CPU_SUP_AMD as the dependence
On Mon, Mar 28, 2016 at 01:32:11PM +0800, Huang Rui wrote: > This patch adds CONFIG_CPU_SUP_AMD as the dependence of fam15h_power > driver. Because the following patch will use the interface from > x86/kernel/cpu/amd.c. > > Otherwise, the below error might be encountered: > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `fam15h_power_probe': > >> fam15h_power.c:(.text+0x26e3a3): undefined reference to > >> `amd_get_cores_per_cu' >fam15h_power.c:(.text+0x26e41e): undefined reference to > `amd_get_cores_per_cu' > > Reported-by: build test robot > Signed-off-by: Huang Rui Acked-by: Borislav Petkov This can go in now, regardless of the rest. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH 8/8] iio: imu: Fix inv_mpu6050 dependencies
On 25/03/16 22:40, Richard Weinberger wrote: > Not all archs have io memory. > Instead of selecting I2C_MUX (and bypassing the HAS_IOMEM dependency) > depend directly on it. > > Fixes the following kconfig warning: > warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) > selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM) > And this build error: > ERROR: "devm_ioremap_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! > ERROR: "of_address_to_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! > > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Lars-Peter Clausen > Cc: Peter Meerwald > Signed-off-by: Richard Weinberger Applied to the fixes-togreg-post-rc1 branch of iio.git. Thanks, Jonathan > --- > drivers/iio/imu/inv_mpu6050/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig > b/drivers/iio/imu/inv_mpu6050/Kconfig > index a7f557a..847455a 100644 > --- a/drivers/iio/imu/inv_mpu6050/Kconfig > +++ b/drivers/iio/imu/inv_mpu6050/Kconfig > @@ -9,9 +9,8 @@ config INV_MPU6050_IIO > > config INV_MPU6050_I2C > tristate "Invensense MPU6050 devices (I2C)" > - depends on I2C > + depends on I2C_MUX > select INV_MPU6050_IIO > - select I2C_MUX > select REGMAP_I2C > help > This driver supports the Invensense MPU6050 devices. >
Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data
On 22-03-16, 02:54, Rafael J. Wysocki wrote:
> Index: linux-pm/kernel/sched/cpufreq_schedutil.c
> ===
> --- /dev/null
> +++ linux-pm/kernel/sched/cpufreq_schedutil.c
> @@ -0,0 +1,528 @@
> +/*
> + * CPUFreq governor based on scheduler-provided CPU utilization data.
> + *
> + * Copyright (C) 2016, Intel Corporation
> + * Author: Rafael J. Wysocki
> + *
> + * 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
> +#include
> +#include
> +#include
> +
> +#include "sched.h"
> +
> +struct sugov_tunables {
> + struct gov_attr_set attr_set;
> + unsigned int rate_limit_us;
> +};
> +
> +struct sugov_policy {
> + struct cpufreq_policy *policy;
> +
> + struct sugov_tunables *tunables;
> + struct list_head tunables_hook;
> +
> + raw_spinlock_t update_lock; /* For shared policies */
> + u64 last_freq_update_time;
> + s64 freq_update_delay_ns;
And why isn't it part of sugov_tunables? Its gonna be same for all policies
sharing tunables ..
> + unsigned int next_freq;
> +
> + /* The next fields are only needed if fast switch cannot be used. */
> + struct irq_work irq_work;
> + struct work_struct work;
> + struct mutex work_lock;
> + bool work_in_progress;
> +
> + bool need_freq_update;
> +};
> +
> +struct sugov_cpu {
> + struct update_util_data update_util;
> + struct sugov_policy *sg_policy;
> +
> + /* The fields below are only needed when sharing a policy. */
> + unsigned long util;
> + unsigned long max;
> + u64 last_update;
> +};
> +
> +static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
> +
> +/ Governor internals ***/
> +
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64
> time)
To make its purpose clear, maybe name it as: sugov_should_reevaluate_freq(),
because we aren't updating the freq just yet, but deciding if we need to
reevaluate again or not.
As its going to be called from hotpath, maybe mark it as inline and let compiler
decide ?
> +{
> + u64 delta_ns;
> +
> + if (sg_policy->work_in_progress)
> + return false;
> +
> + if (unlikely(sg_policy->need_freq_update)) {
> + sg_policy->need_freq_update = false;
> + return true;
> + }
> +
> + delta_ns = time - sg_policy->last_freq_update_time;
> + return (s64)delta_ns >= sg_policy->freq_update_delay_ns;
> +}
> +
> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
Maybe sugov_update_freq() ?
> + unsigned int next_freq)
> +{
> + struct cpufreq_policy *policy = sg_policy->policy;
> +
> + sg_policy->last_freq_update_time = time;
> +
> + if (policy->fast_switch_enabled) {
> + if (next_freq > policy->max)
> + next_freq = policy->max;
> + else if (next_freq < policy->min)
> + next_freq = policy->min;
> +
> + if (sg_policy->next_freq == next_freq) {
> + trace_cpu_frequency(policy->cur, smp_processor_id());
> + return;
> + }
> + sg_policy->next_freq = next_freq;
Why not do all of above stuff as part of else block as well and move it before
the if {} block ?
> + next_freq = cpufreq_driver_fast_switch(policy, next_freq);
> + if (next_freq == CPUFREQ_ENTRY_INVALID)
> + return;
> +
> + policy->cur = next_freq;
> + trace_cpu_frequency(next_freq, smp_processor_id());
> + } else if (sg_policy->next_freq != next_freq) {
> + sg_policy->next_freq = next_freq;
> + sg_policy->work_in_progress = true;
> + irq_work_queue(&sg_policy->irq_work);
> + }
> +}
> +
> +/**
> + * get_next_freq - Compute a new frequency for a given cpufreq policy.
> + * @policy: cpufreq policy object to compute the new frequency for.
> + * @util: Current CPU utilization.
> + * @max: CPU capacity.
> + *
> + * If the utilization is frequency-invariant, choose the new frequency to be
> + * proportional to it, that is
> + *
> + * next_freq = C * max_freq * util / max
> + *
> + * Otherwise, approximate the would-be frequency-invariant utilization by
> + * util_raw * (curr_freq / max_freq) which leads to
> + *
> + * next_freq = C * curr_freq * util_raw / max
> + *
> + * Take C = 1.25 for the frequency tipping point at (util / max) = 0.8.
> + */
> +static unsigned int get_next_freq(struct cpufreq_policy *policy,
> + unsigned long util, unsigned long max)
> +{
> + unsigned int freq = arch_scale_freq_invariant() ?
> + policy->cpuinfo.max_freq : policy->cur;
> +
> + return (freq + (freq >> 2)) * util / max;
Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On 28 March 2016 at 15:13, Peter Chen wrote: > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote: >> On 25 March 2016 at 15:09, Peter Chen wrote: >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote: >> >> Currently the Linux kernel does not provide any standard integration of >> >> this >> >> feature that integrates the USB subsystem with the system power regulation >> >> provided by PMICs meaning that either vendors must add this in their >> >> kernels >> >> or USB gadget devices based on Linux (such as mobile phones) may not >> >> behave >> >> as they should. Thus provide a standard framework for doing this in >> >> kernel. >> >> >> >> Now introduce one user with wm831x_power to support and test the usb >> >> charger, >> >> which is pending testing. Moreover there may be other potential users >> >> will use >> >> it in future. >> >> >> > >> > I am afraid I still not find the user (udc driver) for this framework, I >> > would >> > like to see how udc driver block the enumeration until the charger >> > detection >> > has finished, or am I missing something? >> >> It is not for udc driver but for power users who want to negotiate >> with USB subsystem. >> > > Then, where is the code the test user to decide what kinds of USB charger > (SDP, CDP, DCP) is connecting now? Users can choose to implement multiple ways to get the charger type In 'usb_charger_detect_type()' function. > > -- > Best Regards, > Peter Chen -- Baolin.wang Best Regards
Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver
Hi Marek,
Firstly, thank you very much for your comments.
On 2016/3/27 9:47, Marek Vasut wrote:
> On 03/26/2016 09:11 AM, Jiancheng Xue wrote:
>> Add hisilicon spi-nor flash controller driver
>>
>> Signed-off-by: Binquan Peng
>> Signed-off-by: Jiancheng Xue
>> Acked-by: Rob Herring
>> Reviewed-by: Ezequiel Garcia
>> Reviewed-by: Jagan Teki
>> ---
>> change log
>> v9:
>> Fixed issues pointed by Jagan Teki.
>
> It'd be really great if you could list which exact issues you fixed.
>
OK. I'll describe the history log more detailed in next version.
>> v8:
>> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
>> Moved dts binding file to mtd directory.
>> Changed the compatible string more specific.
>
> [...]
>
>> +/* Hardware register offsets and field definitions */
>> +#define FMC_CFG 0x00
>> +#define SPI_NOR_ADDR_MODE BIT(10)
>> +#define FMC_GLOBAL_CFG 0x04
>> +#define FMC_GLOBAL_CFG_WP_ENABLEBIT(6)
>> +#define FMC_SPI_TIMING_CFG 0x08
>> +#define TIMING_CFG_TCSH(nr) (((nr) & 0xf) << 8)
>> +#define TIMING_CFG_TCSS(nr) (((nr) & 0xf) << 4)
>> +#define TIMING_CFG_TSHSL(nr)((nr) & 0xf)
>> +#define CS_HOLD_TIME0x6
>> +#define CS_SETUP_TIME 0x6
>> +#define CS_DESELECT_TIME0xf
>> +#define FMC_INT 0x18
>> +#define FMC_INT_OP_DONE BIT(0)
>> +#define FMC_INT_CLR 0x20
>> +#define FMC_CMD 0x24
>> +#define FMC_CMD_CMD1(_cmd) ((_cmd) & 0xff)
>
> Drop the underscores in the argument names.
>
OK.
>> +#define FMC_ADDRL 0x2c
>> +#define FMC_OP_CFG 0x30
>> +#define OP_CFG_FM_CS(_cs) ((_cs) << 11)
>> +#define OP_CFG_MEM_IF_TYPE(_type) (((_type) & 0x7) << 7)
>> +#define OP_CFG_ADDR_NUM(_addr) (((_addr) & 0x7) << 4)
>> +#define OP_CFG_DUMMY_NUM(_dummy)((_dummy) & 0xf)
>> +#define FMC_DATA_NUM0x38
>> +#define FMC_DATA_NUM_CNT(_n)((_n) & 0x3fff)
>> +#define FMC_OP 0x3c
>> +#define FMC_OP_DUMMY_EN BIT(8)
>> +#define FMC_OP_CMD1_EN BIT(7)
>> +#define FMC_OP_ADDR_EN BIT(6)
>> +#define FMC_OP_WRITE_DATA_ENBIT(5)
>> +#define FMC_OP_READ_DATA_EN BIT(2)
>> +#define FMC_OP_READ_STATUS_EN BIT(1)
>> +#define FMC_OP_REG_OP_START BIT(0)
>
> [...]
>
>> +enum hifmc_iftype {
>> +IF_TYPE_STD,
>> +IF_TYPE_DUAL,
>> +IF_TYPE_DIO,
>> +IF_TYPE_QUAD,
>> +IF_TYPE_QIO,
>> +};
>> +
>> +struct hifmc_priv {
>> +int chipselect;
>
> Can chipselect be set to < 0 values ?
>
The type will be changed to u32.
>> +u32 clkrate;
>> +struct hifmc_host *host;
>> +};
>> +
>> +#define HIFMC_MAX_CHIP_NUM 2
>
> This does not scale very well, use dynamic allocation.
>
OK. Dynamic allocation will be used in next version.
>> +struct hifmc_host {
>> +struct device *dev;
>> +struct mutex lock;
>> +
>> +void __iomem *regbase;
>> +void __iomem *iobase;
>> +struct clk *clk;
>> +void *buffer;
>> +dma_addr_t dma_buffer;
>> +
>> +struct spi_nor nor[HIFMC_MAX_CHIP_NUM];
>> +struct hifmc_priv priv[HIFMC_MAX_CHIP_NUM];
>> +int num_chip;
>> +};
>> +
>> +static inline int wait_op_finish(struct hifmc_host *host)
>> +{
>> +unsigned int reg;
>> +
>> +return readl_poll_timeout(host->regbase + FMC_INT, reg,
>> +(reg & FMC_INT_OP_DONE), 0, FMC_WAIT_TIMEOUT);
>> +}
>> +
>> +static int get_if_type(enum read_mode flash_read)
>> +{
>> +enum hifmc_iftype if_type;
>> +
>> +switch (flash_read) {
>> +case SPI_NOR_DUAL:
>> +if_type = IF_TYPE_DUAL;
>> +break;
>> +case SPI_NOR_QUAD:
>> +if_type = IF_TYPE_QUAD;
>> +break;
>> +case SPI_NOR_NORMAL:
>> +case SPI_NOR_FAST:
>> +default:
>> +if_type = IF_TYPE_STD;
>> +break;
>> +}
>> +
>> +return if_type;
>> +}
>> +
>> +static void hisi_spi_nor_init(struct hifmc_host *host)
>> +{
>> +unsigned int reg;
>
> Should be u32 here.
>
OK.
>> +reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
>> +| TIMING_CFG_TCSS(CS_SETUP_TIME)
>> +| TIMING_CFG_TSHSL(CS_DESELECT_TIME);
>> +writel(reg, host->regbase + FMC_SPI_TIMING_CFG);
>> +}
>> +
>> +static int hisi_spi_nor_prep(struct spi_nor *nor, enum spi_nor_ops ops)
>> +{
>> +struct hifmc_priv *priv = nor->priv;
>> +struct hifmc_host *host = priv->host;
>> +int ret;
>> +
>> +mutex_lock(&host->lock);
>
> Why do you need the mutex lock here ? Let me guess -- SPI NOR framework
> locks a mutex in struct spi_nor , but that's not enough if you have
> multiple SPI NORs on the same bus, because concurrent access to multiple
> SPI NOR flashes needs locking on the contro
Re: [PATCH 28/31] iio: gyro: use parity32 in adxrs450.c
On 03/28/2016 10:35 AM, Jonathan Cameron wrote: > On 27/03/16 08:42, zhaoxiu.zeng wrote: >> From: Zeng Zhaoxiu >> >> Signed-off-by: Zeng Zhaoxiu > Interesting. Whilst obviously correct I wonder if this obscures the > intent of the code a little. Lars, what do you think? The parity function is newly introduced in this series and can be more efficient that just hw_weight() & 1 on certain architectures. Since the result is the same using it is certainly an improvement. But ... [...] >> -if (!(hweight32(tx) & 1)) >> -tx |= ADXRS450_P; >> +tx |= !parity32(tx) * ADXRS450_P; ... this should still be if (!parity32(tx)) tx |= ADXRS450_P; Otherwise it's a bit too much obfuscated for my taste. Just leave it to the compiler to optimize it as it sees it fit.
[PATCH v3 3/5] dt-bindings: Add documentation for GM20B GPU
GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.
Signed-off-by: Alexandre Courbot
Acked-by: Rob Herring
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 29 +++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
index 1e3748337319..ff3db65e50de 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
@@ -1,9 +1,10 @@
-NVIDIA GK20A Graphics Processing Unit
+NVIDIA Tegra Graphics Processing Units
Required properties:
- compatible: "nvidia,"
Currently recognized values:
- nvidia,gk20a
+ - nvidia,gm20b
- reg: Physical base address and length of the controller's registers.
Must contain two entries:
- first entry for bar0
@@ -19,6 +20,9 @@ Required properties:
- clock-names: Must include the following entries:
- gpu
- pwr
+If the compatible string is "nvidia,gm20b", then the following clock
+is also required:
+ - ref
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
@@ -27,9 +31,9 @@ Required properties:
Optional properties:
- iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
-Example:
+Example for GK20A:
- gpu@0,5700 {
+ gpu@5700 {
compatible = "nvidia,gk20a";
reg = <0x0 0x5700 0x0 0x0100>,
<0x0 0x5800 0x0 0x0100>;
@@ -45,3 +49,22 @@ Example:
iommus = <&mc TEGRA_SWGROUP_GPU>;
status = "disabled";
};
+
+Example for GM20B:
+
+ gpu@5700 {
+ compatible = "nvidia,gm20b";
+ reg = <0x0 0x5700 0x0 0x0100>,
+ <0x0 0x5800 0x0 0x0100>;
+ interrupts = ,
+;
+ interrupt-names = "stall", "nonstall";
+ clocks = <&tegra_car TEGRA210_CLK_GPU>,
+<&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
+<&tegra_car TEGRA210_CLK_PLL_G_REF>;
+ clock-names = "gpu", "pwr", "ref";
+ resets = <&tegra_car 184>;
+ reset-names = "gpu";
+ iommus = <&mc TEGRA_SWGROUP_GPU>;
+ status = "disabled";
+ };
--
2.7.3
[PATCH v3 0/5] arm64: tegra: fix DT definitions for GM20B GPU
Small series that fixes/completes DT bindings for Tegra GPUs and add two missing entries required for the Tegra210 GPU to operate properly. Without these fixes, GM20B will crash during probe on 4.6 because a required clock is not activated. Changes since v2: - Fixed device address in DT examples - Carried Acked-bys Changes since v1: - Renamed "pllg_ref" clock to "ref" in DT bindings Alexandre Courbot (5): dt-bindings: gk20a: Fix typo in compatible name dt-bindings: gk20a: Document iommus property dt-bindings: Add documentation for GM20B GPU arm64: tegra210: Add reference clock to GM20B arm64: tegra210: Add IOMMU node to GM20B .../devicetree/bindings/gpu/nvidia,gk20a.txt | 37 +++--- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 8 +++-- 2 files changed, 38 insertions(+), 7 deletions(-) -- 2.7.3
[PATCH v3 2/5] dt-bindings: gk20a: Document iommus property
GK20A can optionally make use of an IOMMU.
Signed-off-by: Alexandre Courbot
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
index 914f0ff4020e..1e3748337319 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
@@ -24,6 +24,9 @@ Required properties:
- reset-names: Must include the following entries:
- gpu
+Optional properties:
+- iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
+
Example:
gpu@0,5700 {
@@ -39,5 +42,6 @@ Example:
clock-names = "gpu", "pwr";
resets = <&tegra_car 184>;
reset-names = "gpu";
+ iommus = <&mc TEGRA_SWGROUP_GPU>;
status = "disabled";
};
--
2.7.3
[PATCH v3 5/5] arm64: tegra210: Add IOMMU node to GM20B
Nouveau can take advantage of this declaration to remove the need for contiguous memory. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi index 04898cb25f0c..478543f74863 100644 --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi @@ -314,6 +314,9 @@ clock-names = "gpu", "pwr", "ref"; resets = <&tegra_car 184>; reset-names = "gpu"; + + iommus = <&mc TEGRA_SWGROUP_GPU>; + status = "disabled"; }; -- 2.7.3
[PATCH v3 4/5] arm64: tegra210: Add reference clock to GM20B
This clock is required for the GPU to operate. Signed-off-by: Alexandre Courbot --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi index 362c269946ff..04898cb25f0c 100644 --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi @@ -309,8 +309,9 @@ ; interrupt-names = "stall", "nonstall"; clocks = <&tegra_car TEGRA210_CLK_GPU>, -<&tegra_car TEGRA210_CLK_PLL_P_OUT5>; - clock-names = "gpu", "pwr"; +<&tegra_car TEGRA210_CLK_PLL_P_OUT5>, +<&tegra_car TEGRA210_CLK_PLL_G_REF>; + clock-names = "gpu", "pwr", "ref"; resets = <&tegra_car 184>; reset-names = "gpu"; status = "disabled"; -- 2.7.3
[PATCH v3 1/5] dt-bindings: gk20a: Fix typo in compatible name
The correct compatible name is "nvidia,gk20a". Signed-off-by: Alexandre Courbot Acked-by: Rob Herring --- Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt index 23bfe8e1f7cc..914f0ff4020e 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt @@ -1,9 +1,9 @@ NVIDIA GK20A Graphics Processing Unit Required properties: -- compatible: "nvidia,-" +- compatible: "nvidia," Currently recognized values: - - nvidia,tegra124-gk20a + - nvidia,gk20a - reg: Physical base address and length of the controller's registers. Must contain two entries: - first entry for bar0 -- 2.7.3
[REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables
Dear Ivan, dear Jeann, There is an unwanted regression due to commit d7f96f97 (firmware: dmi_scan: add SBMIOS entry and DMI tables). Since Linux kernel 4.2 the utility `cbmem`, used to access information stored in memory, from the coreboot project [1] does not work anymore on a lot of systems as reported in coreboot’s issue tracker as ticket #33 [2]. ``` Failed to mmap /dev/mem: Resource temporarily unavailable ``` Aaron Durbin analyzed on the coreboot mailing list [3]: > > 3) Why is that range set as uncached-minus? Would write-back work? > > Please see this thread: > http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html > > The actual issue stems from > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f > which maintains a persistent mapping of smbios tables. It uses > dmi_remap() which is '#define dmi_remap ioremap' which is where the > uncached-minus PAT entry comes from. It should be using the same > mechanism as the ACPI table mappings which uses ioremap_cache(). It’d be great, if the commit could be reverted, or the code be changed in a way that `cbmem` still works. If I should report this issue somewhere else, please tell me too, and I’ll do my best to follow up there. Thanks, Paul [1] https://www.coreboot.org [2] https://ticket.coreboot.org/issues/33 [3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html signature.asc Description: This is a digitally signed message part
[PATCH 1/5] drm: Add new DCS commands in the enum list
Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.
v2: Sorted the Macro`s by value (Andrzej)
Cc: Andrzej Hajda
Cc: Thierry Reding
Cc: David Airlie
Cc: Ville Syrjälä
Cc: Daniel Vetter
Suggested-by: Jani Nikula
Signed-off-by: Deepak M
---
include/video/mipi_display.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index ddcc8ca..6831c84 100644
--- a/include/video/mipi_display.h
+++ b/include/video/mipi_display.h
@@ -117,6 +117,14 @@ enum {
MIPI_DCS_GET_SCANLINE = 0x45,
MIPI_DCS_READ_DDB_START = 0xA1,
MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
+ MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /*Spec 1.3*/
+ MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /*Spec 1.3*/
+ MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53, /*Spec 1.3*/
+ MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /*Spec 1.3*/
+ MIPI_DCS_WRITE_POWER_SAVE = 0x55, /*Spec 1.3*/
+ MIPI_DCS_GET_POWER_SAVE = 0x56, /*Spec 1.3*/
+ MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E, /*Spec 1.3*/
+ MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F, /*Spec 1.3*/
};
/* MIPI DCS pixel formats */
--
1.9.1
Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit accumulated power
On Mon, Mar 28, 2016 at 01:32:12PM +0800, Huang Rui wrote:
> This patch adds a member in fam15h_power_data which specifies the
> compute unit accumulated power. It adds do_read_registers_on_cu to do
> all the read to all MSRs and run it on one of the online cores on each
> compute unit with smp_call_function_many(). This behavior can decrease
> IPI numbers.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Huang Rui
> ---
> drivers/hwmon/fam15h_power.c | 65
> +++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 4f695d8..ccbc944 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -25,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -44,7 +46,9 @@ MODULE_LICENSE("GPL");
>
> #define FAM15H_MIN_NUM_ATTRS 2
> #define FAM15H_NUM_GROUPS2
> +#define MAX_CUS 8
>
> +#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
>
> #define PCI_DEVICE_ID_AMD_15H_M70H_NB_F4 0x15b4
> @@ -59,6 +63,8 @@ struct fam15h_power_data {
> struct attribute_group group;
> /* maximum accumulated power of a compute unit */
> u64 max_cu_acc_power;
> + /* accumulated power of the compute units */
> + u64 cu_acc_power[MAX_CUS];
> };
>
> static ssize_t show_power(struct device *dev,
> @@ -125,6 +131,63 @@ static ssize_t show_power_crit(struct device *dev,
> }
> static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>
> +static void do_read_registers_on_cu(void *_data)
> +{
> + struct fam15h_power_data *data = _data;
> + int cpu, cu;
> +
> + cpu = smp_processor_id();
> +
> + /*
> + * With the new x86 topology modelling, cpu core id actually
> + * is compute unit id.
> + */
> + cu = cpu_data(cpu).cpu_core_id;
> +
> + rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, &data->cu_acc_power[cu]);
> +}
> +
> +/*
> + * This function is only able to be called when CPUID
> + * Fn8000_0007:EDX[12] is set.
> + */
> +static int read_registers(struct fam15h_power_data *data)
> +{
> + int this_cpu, ret, cpu;
> + int target;
> + cpumask_var_t mask;
> +
> + ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
> + if (!ret)
> + return -ENOMEM;
> +
> + get_online_cpus();
> + this_cpu = get_cpu();
What now?
get_online_cpus() is enough.
> +
> + /*
> + * Choose the first online core of each compute unit, and then
> + * read their MSR value of power and ptsc in a single IPI,
> + * because the MSR value of CPU core represent the compute
> + * unit's.
> + */
> + for_each_online_cpu(cpu) {
> + target = cpumask_first(topology_sibling_cpumask(cpu));
> + if (!cpumask_test_cpu(target, mask))
> + cpumask_set_cpu(target, mask);
> + }
I think you want something like this: iterate over each core and put one
of them into the mask.
core = -1;
for_each_online_cpu(cpu) {
this_core = topology_core_id(cpu);
if (this_core == core)
continue;
core = this_core;
/* get any CPU on this compute unit */
cpumask_set_cpu(cpumask_any(topology_sibling_cpumask(cpu)),
mask);
}
Btw, tglx, peterz, do you guys think it would make sense to have a
generic helper:
for_each_core(cpu)
which would give you any of the threads on the core in the @cpu var when
iterating?
I see only arch/x86/events/intel/cstate.c doing any comparisons with
topology_core_id() now but it might be useful...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Re: [PATCH v5 4/6] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm
On Mon, Mar 28, 2016 at 01:32:14PM +0800, Huang Rui wrote:
> This patch introduces an algorithm that computes the average power by
> reading a delta value of “core power accumulator” register during
> measurement interval, and then dividing delta value by the length of
> the time interval.
>
> User is able to use power1_average entry to measure the processor power
> consumption and power1_average_interval entry to set the interval.
>
> A simple example:
>
> ray@hr-ub:~/tip$ sensors
> fam15h_power-pci-00c4
> Adapter: PCI adapter
> power1: 19.58 mW (avg = 2.55 mW, interval = 0.01 s)
>(crit = 15.00 W)
>
> ...
>
> The result is current average processor power consumption in 10
> millisecond. The unit of the result is uWatt.
>
> Suggested-by: Guenter Roeck
> Signed-off-by: Huang Rui
> Cc: Borislav Petkov
> ---
> drivers/hwmon/fam15h_power.c | 119
> +++
> 1 file changed, 119 insertions(+)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index de6f52b..003564b 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -48,6 +50,9 @@ MODULE_LICENSE("GPL");
> #define FAM15H_NUM_GROUPS2
> #define MAX_CUS 8
>
> +/* set maximum interval as 1 second */
> +#define MAX_INTERVAL 1000
> +
> #define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
> #define MSR_F15H_PTSC0xc0010280
> @@ -68,6 +73,9 @@ struct fam15h_power_data {
> u64 cu_acc_power[MAX_CUS];
> /* performance timestamp counter */
> u64 cpu_sw_pwr_ptsc[MAX_CUS];
> + /* online/offline status of current compute unit */
> + int cu_on[MAX_CUS];
> + unsigned long power_period;
> };
>
> static ssize_t show_power(struct device *dev,
> @@ -149,6 +157,8 @@ static void do_read_registers_on_cu(void *_data)
>
> rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, &data->cu_acc_power[cu]);
> rdmsrl_safe(MSR_F15H_PTSC, &data->cpu_sw_pwr_ptsc[cu]);
> +
> + data->cu_on[cu] = 1;
> }
>
> /*
> @@ -165,6 +175,8 @@ static int read_registers(struct fam15h_power_data *data)
> if (!ret)
> return -ENOMEM;
>
> + memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
> +
> get_online_cpus();
> this_cpu = get_cpu();
>
> @@ -192,18 +204,117 @@ static int read_registers(struct fam15h_power_data
> *data)
> return 0;
> }
>
> +static ssize_t acc_show_power(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct fam15h_power_data *data = dev_get_drvdata(dev);
> + u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
> + jdelta[MAX_CUS];
> + u64 tdelta, avg_acc;
> + int cu, cu_num, ret;
> + signed long leftover;
> +
> + /*
> + * With the new x86 topology modelling, x86_max_cores is the
> + * compute unit number.
> + */
> + cu_num = boot_cpu_data.x86_max_cores;
> +
> + ret = read_registers(data);
> + if (ret)
> + return 0;
> +
> + for (cu = 0; cu < cu_num; cu++) {
> + prev_cu_acc_power[cu] = data->cu_acc_power[cu];
> + prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
> + }
> +
> + leftover =
> schedule_timeout_interruptible(msecs_to_jiffies(data->power_period));
> + if (leftover)
> + return 0;
> +
> + ret = read_registers(data);
> + if (ret)
> + return 0;
> +
> + for (cu = 0, avg_acc = 0; cu < cu_num; cu++) {
> + /* check if current compute unit is online */
> + if (data->cu_on[cu] == 0)
> + continue;
> +
> + if (data->cu_acc_power[cu] < prev_cu_acc_power[cu]) {
> + jdelta[cu] = data->max_cu_acc_power +
> data->cu_acc_power[cu];
> + jdelta[cu] -= prev_cu_acc_power[cu];
> + } else {
> + jdelta[cu] = data->cu_acc_power[cu] -
> prev_cu_acc_power[cu];
> + }
> + tdelta = data->cpu_sw_pwr_ptsc[cu] - prev_ptsc[cu];
> + jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> + do_div(jdelta[cu], tdelta);
> +
> + /* the unit is microWatt */
> + avg_acc += jdelta[cu];
> + }
> +
> + return sprintf(buf, "%llu\n", (unsigned long long)avg_acc);
> +}
> +static DEVICE_ATTR(power1_average, S_IRUGO, acc_show_power, NULL);
> +
> +static ssize_t acc_show_power_period(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct fam15h_power_data *data = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%lu\n", data->power_perio
Re: ARC dw-mshc binding compat string
Hi Marek, Vladimir,
On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
> >
> > On 26.03.2016 21:52, Marek Vasut wrote:
> > >
> > > On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
> > > >
> > > > On 26.03.2016 20:10, Marek Vasut wrote:
> > > > >
> > > > > On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
> > > > > >
> > > > > > Hi Marek,
> > > > > >
> > > > > > On 26.03.2016 19:30, Marek Vasut wrote:
> > > > > > >
> > > > > > > On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
> > > > > > > >
> > > > > > > > On 26.03.2016 12:14, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > > Hi!
> > > > > > > > >
> > > > > > > > > I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr,"
> > > > > > > > > prefix in
> > > > > > > > > the DT compatible string:
> > > > > > > > >
> > > > > > > > > mmc@0x15000 {
> > > > > > > > > compatible = "altr,socfpga-dw-mshc";
> > > > > > > > > reg = < 0x15000 0x400 >;
> > > > > > > > > num-slots = < 1 >;
> > > > > > > > > fifo-depth = < 16 >;
> > > > > > > > > card-detect-delay = < 200 >;
> > > > > > > > > clocks = <&apbclk>, <&mmcclk>;
> > > > > > > > > clock-names = "biu", "ciu";
> > > > > > > > > interrupts = < 7 >;
> > > > > > > > > bus-width = < 4 >;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > I don't think this is OK, since ARC is unrelated to Altera,
> > > > > > > > > which is
> > > > > > > > > what the "altr," prefix stands for. I think the
> > > > > > > > > socfpga-dw-mshc shim
> > > > > > > > > should be extended with another compatibility string,
> > > > > > > > > something like
> > > > > > > > > "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
> > > > > > > > > accordingly. What do you think ?
> > > > > > > > >
> > > > > > > > There is "snps,dw-mshc" described in
> > > > > > > > Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and
> > > > > > > > supported by
> > > > > > > > dw_mmc host controller driver.
> > > > > > > Thanks, that's even better.
> > > > > > >
> > > > > > > btw what do you think of using altr, prefix on non-altera system,
> > > > > > > that
> > > > > > > doesn't seem ok, right ?
> > > > > > according to ePAPR the prefix should represent a device (IP block
> > > > > > here
> > > > > > I believe) manufacturer, so it should be okay to use "altr" prefix
> > > > > > on
> > > > > > non-Altera system, if Altera provides another hardware vendor with
> > > > > > some own IP block.
> > > > > In this case, it's Synopsys who provides the SD/MMC/MS core to other
> > > > > chip makers (Altera etc).
> > > > Correct.
> > > >
> > > > >
> > > > > >
> > > > > > That said, I would rather prefer to see "snps,dw-mshc" prefix on
> > > > > > description
> > > > > > of an MMC controller found on SoCFPGA series,
> > > > > > "altr,socfpga-dw-mshc" seems
> > > > > > to be redundant.
> > > > > According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
> > > > > "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
> > > > > "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
> > > > > while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
> > > > > one needs it as well, but most likely yes.
> > > > >
> > > > > I wonder if that bit is needed on some particular version of the DWMMC
> > > > > core. In that case, should we have "snps,dw-mshc" and
> > > > > "snps,dw-mshc-vN"
> > > > > binding ? Or should we use DT property to discern the need for this
> > > > > bit ?
> > > > >
> > > > That's the most common way to take into account peculiarities, add
> > > > a property and handle it from the driver.
> > > And by "that" you mean which of those two I listed , the
> > > "snps,dw-mshc-vN" or adding new DT prop ?
> > >
> > I meant to add a new property, not a new compatible, but that's just
> > my experience.
> >
> > Let me say it __might__ happen that a particular change you need is
> > specific to a particular version of the DWMMC IP (query Synopsys
> > by the way), but more probably it might be e.g. the same IP version with
> > a different reduced or extended configuration or a minor fix/improvement
> > to the IP block without resulting version number bump.
> >
> > For example I don't remember that errata fixes in IP blocks result in
> > a new compatible, instead there are quite common optional "quirk"
> > properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
> Right, this very much matches how I see it as well. Thanks for confirming.
>
> Alexey, can you tell us if the requirement for setting
> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
> disappeared with some revision OR if this is some configuration
> option of the core during synthesis ?
Sorry for not following that discussion during my weekend but I'll try
to address all questions now.
DW Mobile Storage databook says:
->8-
Re: [PATCH] arm: dts: mt2701: Add clock controller device nodes
On 28/03/2016 10:13, kbuild test robot wrote: > Hi James, > > [auto build test ERROR on robh/for-next] > [also build test ERROR on v4.6-rc1 next-20160327] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/James-Liao/arm-dts-mt2701-Add-clock-controller-device-nodes/20160328-133113 > base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next > config: arm-multi_v7_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All errors (new ones prefixed by >>): > >In file included from arch/arm/boot/dts/mt2701-evb.dts:16:0: >>> arch/arm/boot/dts/mt2701.dtsi:15:42: fatal error: >>> dt-bindings/clock/mt2701-clk.h: No such file or directory > #include Hi James, looks like the mt2701 clock patches did not make it into v4.6-rc1. i had a few minor fixes i wanted to send this week for MT7623 support and noticed this last week already :( John > ^ >compilation terminated. > > vim +15 arch/arm/boot/dts/mt2701.dtsi > > 9 * This program is distributed in the hope that it will be > useful, > 10 * but WITHOUT ANY WARRANTY; without even the implied warranty > of > 11 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > 12 * GNU General Public License for more details. > 13 */ > 14 > > 15#include > 16#include > 17#include > 18#include "skeleton64.dtsi" > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek >
Re: [PATCH 1/6] iio: accel: bmc150: use available_scan_masks
On 24/03/16 09:29, Irina Tirdea wrote:
> Use available_scan_masks to allow the iio core to select
> the data to send to userspace depending on which axes are
> enabled, instead of doing this in the driver's interrupt
> handler.
>
> Signed-off-by: Irina Tirdea
Applied to the togreg branch of iio.git.
Thanks,
> ---
> drivers/iio/accel/bmc150-accel-core.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c
> b/drivers/iio/accel/bmc150-accel-core.c
> index c73331f7..cc52366 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -138,6 +138,7 @@ enum bmc150_accel_axis {
> AXIS_X,
> AXIS_Y,
> AXIS_Z,
> + AXIS_MAX,
> };
>
> enum bmc150_power_modes {
> @@ -1104,6 +1105,10 @@ static const struct iio_info bmc150_accel_info_fifo = {
> .driver_module = THIS_MODULE,
> };
>
> +static const unsigned long bmc150_accel_scan_masks[] = {
> + BIT(AXIS_X) | BIT(AXIS_Y) | BIT(AXIS_Z),
> + 0};
> +
> static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
> {
> struct iio_poll_func *pf = p;
> @@ -1113,8 +1118,7 @@ static irqreturn_t bmc150_accel_trigger_handler(int
> irq, void *p)
> unsigned int raw_val;
>
> mutex_lock(&data->mutex);
> - for_each_set_bit(bit, indio_dev->active_scan_mask,
> - indio_dev->masklength) {
> + for (bit = 0; bit < AXIS_MAX; bit++) {
> ret = regmap_bulk_read(data->regmap,
> BMC150_ACCEL_AXIS_TO_REG(bit), &raw_val,
> 2);
> @@ -1574,6 +1578,7 @@ int bmc150_accel_core_probe(struct device *dev, struct
> regmap *regmap, int irq,
> indio_dev->channels = data->chip_info->channels;
> indio_dev->num_channels = data->chip_info->num_channels;
> indio_dev->name = name ? name : data->chip_info->name;
> + indio_dev->available_scan_masks = bmc150_accel_scan_masks;
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &bmc150_accel_info;
>
>
[PATCH v6 2/3] clk: rockchip: add dt-binding header for rk3399
Add the dt-bindings header for the rk3399, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Xing Zheng Signed-off-by: Jianqun Xu Acked-by: Rob Herring --- Changes in v6: None Changes in v5: - add some necessary clock IDs - keep PPLL independent into the part of the PMUCRU - fix PMUCRU IDs are out of range Changes in v3: None Changes in v2: None include/dt-bindings/clock/rk3399-cru.h | 752 1 file changed, 752 insertions(+) create mode 100644 include/dt-bindings/clock/rk3399-cru.h diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h new file mode 100644 index 000..244746e --- /dev/null +++ b/include/dt-bindings/clock/rk3399-cru.h @@ -0,0 +1,752 @@ +/* + * Copyright (c) 2016 Rockchip Electronics Co. Ltd. + * Author: Xing Zheng + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H + +/* core clocks */ +#define PLL_APLLL 1 +#define PLL_APLLB 2 +#define PLL_DPLL 3 +#define PLL_CPLL 4 +#define PLL_GPLL 5 +#define PLL_NPLL 6 +#define PLL_VPLL 7 +#define ARMCLKL8 +#define ARMCLKB9 + +/* sclk gates (special clocks) */ +#define SCLK_I2C1 65 +#define SCLK_I2C2 66 +#define SCLK_I2C3 67 +#define SCLK_I2C5 68 +#define SCLK_I2C6 69 +#define SCLK_I2C7 70 +#define SCLK_SPI0 71 +#define SCLK_SPI1 72 +#define SCLK_SPI2 73 +#define SCLK_SPI4 74 +#define SCLK_SPI5 75 +#define SCLK_SDMMC 76 +#define SCLK_SDIO 77 +#define SCLK_EMMC 78 +#define SCLK_TSADC 79 +#define SCLK_SARADC80 +#define SCLK_UART0 81 +#define SCLK_UART1 82 +#define SCLK_UART2 83 +#define SCLK_UART3 84 +#define SCLK_SPDIF_8CH 85 +#define SCLK_I2S0_8CH 86 +#define SCLK_I2S1_8CH 87 +#define SCLK_I2S2_8CH 88 +#define SCLK_I2S_8CH_OUT 89 +#define SCLK_TIMER00 90 +#define SCLK_TIMER01 91 +#define SCLK_TIMER02 92 +#define SCLK_TIMER03 93 +#define SCLK_TIMER04 94 +#define SCLK_TIMER05 95 +#define SCLK_TIMER06 96 +#define SCLK_TIMER07 97 +#define SCLK_TIMER08 98 +#define SCLK_TIMER09 99 +#define SCLK_TIMER10 100 +#define SCLK_TIMER11 101 +#define SCLK_MACREF102 +#define SCLK_MAC_RX103 +#define SCLK_MAC_TX104 +#define SCLK_MAC 105 +#define SCLK_MACREF_OUT106 +#define SCLK_VOP0_PWM 107 +#define SCLK_VOP1_PWM 108 +#define SCLK_RGA 109 +#define SCLK_ISP0 110 +#define SCLK_ISP1 111 +#define SCLK_HDMI_CEC 112 +#define SCLK_HDMI_SFR 113 +#define SCLK_DP_CORE 114 +#define SCLK_PVTM_CORE_L 115 +#define SCLK_PVTM_CORE_B 116 +#define SCLK_PVTM_GPU 117 +#define SCLK_PVTM_DDR 118 +#define SCLK_MIPIDPHY_REF 119 +#define SCLK_MIPIDPHY_CFG 120 +#define SCLK_HSICPHY 121 +#define SCLK_USBPHY480M122 +#define SCLK_USB2PHY0_REF 123 +#define SCLK_USB2PHY1_REF 124 +#define SCLK_UPHY0_TCPDPHY_REF 125 +#define SCLK_UPHY0_TCPDCORE126 +#define SCLK_UPHY1_TCPDPHY_REF 127 +#define SCLK_UPHY1_TCPDCORE128 +#define SCLK_USB3OTG0_REF 129 +#define SCLK_USB3OTG1_REF 130 +#define SCLK_USB3OTG0_SUSPEND 131 +#define SCLK_USB3OTG1_SUSPEND 132 +#define SCLK_CRYPTO0 133 +#define SCLK_CRYPTO1 134 +#d
[PATCH v6 0/3] Add more clock compatible features and support the RK3399 clock
Hi, The patch series add support more mux parameters and multiple clock providers for the rockchip features of the clock framework, and support the clock controller for the RK3399. Changes in v6: - update some clock contents - fix the source of the pclkin_isp1_wrapper should be pclkin_cif - remove unused the GRF reference in the clock driver - use the frac mux type for spdif and i2s - remove useless defines RK3399_PMU_RSTNHOLD_CON and RK3399_PMU_GATEDIS_CON Changes in v5: - add some necessary clock IDs - keep PPLL independent into the part of the PMUCRU - fix PMUCRU IDs are out of range - add clock IDs to drivers reference - fix some important bugs - fix configuration for cpu tables Changes in v3: - rename pclkin_cif to pclkin_cifmux, add diagram and comment for pclkin_cifmux - add the clk_test node - modify the cif_testout path - include two new patches that dt-bindings and header file from Jianqun's patch series Changes in v2: - rename the aplll/apllb to lpll/bpll - add drv/sample clock nodes for sdmmc/sdio Xing Zheng (3): dt-bindings: add bindings for rk3399 clock controller clk: rockchip: add dt-binding header for rk3399 clk: rockchip: add clock controller for the RK3399 .../bindings/clock/rockchip,rk3399-cru.txt | 68 + drivers/clk/rockchip/Makefile |1 + drivers/clk/rockchip/clk-rk3399.c | 1540 drivers/clk/rockchip/clk.h | 22 +- include/dt-bindings/clock/rk3399-cru.h | 752 ++ 5 files changed, 2382 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt create mode 100644 drivers/clk/rockchip/clk-rk3399.c create mode 100644 include/dt-bindings/clock/rk3399-cru.h -- 1.7.9.5
[PATCH v6 3/3] clk: rockchip: add clock controller for the RK3399
Add the clock tree definition for the new RK3399 SoC.
Signed-off-by: Xing Zheng
---
Changes in v6:
- fix the source of the pclkin_isp1_wrapper should be pclkin_cif
- remove unused the GRF reference in the clock driver
- use the frac mux type for spdif and i2s
- remove useless defines RK3399_PMU_RSTNHOLD_CON and RK3399_PMU_GATEDIS_CON
Changes in v5:
- add clock IDs to drivers reference
- fix some important bugs
- fix configuration for cpu tables
Changes in v3:
- rename pclkin_cif to pclkin_cifmux, add diagram and comment for
pclkin_cifmux
- add the clk_test node
- modify the cif_testout path
- include two new patches that dt-bindings and header file from
Jianqun's patch series
Changes in v2:
- rename the aplll/apllb to lpll/bpll
- add drv/sample clock nodes for sdmmc/sdio
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-rk3399.c | 1540 +
drivers/clk/rockchip/clk.h| 22 +-
3 files changed, 1562 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-rk3399.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index 80b9a37..f47a2fa 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -15,3 +15,4 @@ obj-y += clk-rk3188.o
obj-y += clk-rk3228.o
obj-y += clk-rk3288.o
obj-y += clk-rk3368.o
+obj-y += clk-rk3399.o
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
new file mode 100644
index 000..356e132
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -0,0 +1,1540 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+enum rk3399_plls {
+ lpll, bpll, dpll, cpll, gpll, npll, vpll,
+};
+
+enum rk3399_pmu_plls {
+ ppll,
+};
+
+static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(220800, 1, 92, 1, 1, 1, 0),
+ RK3036_PLL_RATE(218400, 1, 91, 1, 1, 1, 0),
+ RK3036_PLL_RATE(216000, 1, 90, 1, 1, 1, 0),
+ RK3036_PLL_RATE(213600, 1, 89, 1, 1, 1, 0),
+ RK3036_PLL_RATE(211200, 1, 88, 1, 1, 1, 0),
+ RK3036_PLL_RATE(208800, 1, 87, 1, 1, 1, 0),
+ RK3036_PLL_RATE(206400, 1, 86, 1, 1, 1, 0),
+ RK3036_PLL_RATE(204000, 1, 85, 1, 1, 1, 0),
+ RK3036_PLL_RATE(201600, 1, 84, 1, 1, 1, 0),
+ RK3036_PLL_RATE(199200, 1, 83, 1, 1, 1, 0),
+ RK3036_PLL_RATE(196800, 1, 82, 1, 1, 1, 0),
+ RK3036_PLL_RATE(194400, 1, 81, 1, 1, 1, 0),
+ RK3036_PLL_RATE(192000, 1, 80, 1, 1, 1, 0),
+ RK3036_PLL_RATE(189600, 1, 79, 1, 1, 1, 0),
+ RK3036_PLL_RATE(187200, 1, 78, 1, 1, 1, 0),
+ RK3036_PLL_RATE(184800, 1, 77, 1, 1, 1, 0),
+ RK3036_PLL_RATE(182400, 1, 76, 1, 1, 1, 0),
+ RK3036_PLL_RATE(18, 1, 75, 1, 1, 1, 0),
+ RK3036_PLL_RATE(177600, 1, 74, 1, 1, 1, 0),
+ RK3036_PLL_RATE(175200, 1, 73, 1, 1, 1, 0),
+ RK3036_PLL_RATE(172800, 1, 72, 1, 1, 1, 0),
+ RK3036_PLL_RATE(170400, 1, 71, 1, 1, 1, 0),
+ RK3036_PLL_RATE(168000, 1, 70, 1, 1, 1, 0),
+ RK3036_PLL_RATE(165600, 1, 69, 1, 1, 1, 0),
+ RK3036_PLL_RATE(163200, 1, 68, 1, 1, 1, 0),
+ RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+ R
[PATCH v6 1/3] dt-bindings: add bindings for rk3399 clock controller
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Signed-off-by: Xing Zheng
Signed-off-by: Jianqun Xu
Acked-by: Rob Herring
---
Changes in v6:
- update some clock contents
Changes in v5: None
Changes in v3: None
Changes in v2: None
.../bindings/clock/rockchip,rk3399-cru.txt | 68
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 000..bb2687d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,68 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "clkin_gmac" - external GMAC clock - optional,
+ - "gmac_phy_rx_clk" - external GMAC RX clock - optional,
+ - "clkin_i2s" - external I2S clock - optional,
+ - "pclkin_cif" - external ISP clock - optional,
+ - "clk_usbphy0_480m" - output clock of the pll in the usbphy0
+ - "clk_usbphy1_480m" - output clock of the pll in the usbphy1
+
+Example: Clock controller node:
+
+ pmucru: pmu-clock-controller@ff75 {
+ compatible = "rockchip,rk3399-pmucru";
+ reg = <0x0 0xff75 0x0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ cru: clock-controller@ff76 {
+ compatible = "rockchip,rk3399-cru";
+ reg = <0x0 0xff76 0x0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@ff1a {
+ compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff18 0x0 0x100>;
+ clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+ clock-names = "baudclk", "apb_pclk";
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
--
1.7.9.5
Re: [PATCH 2/6] iio: accel: bmc150: optimize transfers in trigger handler
On 24/03/16 09:29, Irina Tirdea wrote:
> Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> enable/disable the bus at each i2c transfer and must wait for
> the enable/disable to happen before sending the data.
>
> When reading data in the trigger handler, the bmc150 accel driver does
> one bus transfer for each axis. This has an impact on the frequency
> of the accelerometer at high sample rates due to additional delays
> introduced by the bus at each transfer.
>
> Reading all axis values in one bus transfer reduces the delays
> introduced by the bus.
>
> Signed-off-by: Irina Tirdea
Applied to the togreg branch of iio.git. Thanks.
There is in theory a potential to slow down obscure cases here, but
what are the chances anyone is actually reading a single axis of
one of these accelerometers and cares about absolute maximum throughput.
Ah well, if they do, they may scream and we'll have to do something
more complex to keep that case fast. That would make this code
a lot more ugly so *fingers crossed* :)
Anyhow, I like this series and the underlying emulated reading
patch a lot.
Jonathan
> ---
> drivers/iio/accel/bmc150-accel-core.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c
> b/drivers/iio/accel/bmc150-accel-core.c
> index cc52366..58df97d 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -989,6 +989,7 @@ static const struct iio_event_spec bmc150_accel_event = {
> .realbits = (bits), \
> .storagebits = 16, \
> .shift = 16 - (bits), \
> + .endianness = IIO_LE, \
> }, \
> .event_spec = &bmc150_accel_event, \
> .num_event_specs = 1\
> @@ -1114,21 +1115,14 @@ static irqreturn_t bmc150_accel_trigger_handler(int
> irq, void *p)
> struct iio_poll_func *pf = p;
> struct iio_dev *indio_dev = pf->indio_dev;
> struct bmc150_accel_data *data = iio_priv(indio_dev);
> - int bit, ret, i = 0;
> - unsigned int raw_val;
> + int ret;
>
> mutex_lock(&data->mutex);
> - for (bit = 0; bit < AXIS_MAX; bit++) {
> - ret = regmap_bulk_read(data->regmap,
> -BMC150_ACCEL_AXIS_TO_REG(bit), &raw_val,
> -2);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - goto err_read;
> - }
> - data->buffer[i++] = raw_val;
> - }
> + ret = regmap_bulk_read(data->regmap, BMC150_ACCEL_REG_XOUT_L,
> +data->buffer, AXIS_MAX * 2);
> mutex_unlock(&data->mutex);
> + if (ret < 0)
> + goto err_read;
>
> iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> pf->timestamp);
>
Re: [PATCH 3/6] iio: gyro: bmg160: use available_scan_masks
On 24/03/16 09:29, Irina Tirdea wrote:
> Use available_scan_masks to allow the iio core to select
> the data to send to userspace depending on which axes are
> enabled, instead of doing this in the driver's interrupt
> handler.
>
> Signed-off-by: Irina Tirdea
Applied,
Thanks,
> ---
> drivers/iio/gyro/bmg160_core.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> index bbce3b0..8d6e5b1 100644
> --- a/drivers/iio/gyro/bmg160_core.c
> +++ b/drivers/iio/gyro/bmg160_core.c
> @@ -116,6 +116,7 @@ enum bmg160_axis {
> AXIS_X,
> AXIS_Y,
> AXIS_Z,
> + AXIS_MAX,
> };
>
> static const struct {
> @@ -763,6 +764,10 @@ static const struct iio_info bmg160_info = {
> .driver_module = THIS_MODULE,
> };
>
> +static const unsigned long bmg160_accel_scan_masks[] = {
> + BIT(AXIS_X) | BIT(AXIS_Y) | BIT(AXIS_Z),
> + 0};
> +
> static irqreturn_t bmg160_trigger_handler(int irq, void *p)
> {
> struct iio_poll_func *pf = p;
> @@ -772,8 +777,7 @@ static irqreturn_t bmg160_trigger_handler(int irq, void
> *p)
> unsigned int val;
>
> mutex_lock(&data->mutex);
> - for_each_set_bit(bit, indio_dev->active_scan_mask,
> - indio_dev->masklength) {
> + for (bit = 0; bit < AXIS_MAX; bit++) {
> ret = regmap_bulk_read(data->regmap, BMG160_AXIS_TO_REG(bit),
> &val, 2);
> if (ret < 0) {
> @@ -1019,6 +1023,7 @@ int bmg160_core_probe(struct device *dev, struct regmap
> *regmap, int irq,
> indio_dev->channels = bmg160_channels;
> indio_dev->num_channels = ARRAY_SIZE(bmg160_channels);
> indio_dev->name = name;
> + indio_dev->available_scan_masks = bmg160_accel_scan_masks;
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &bmg160_info;
>
>
[PATCH 4/4 -v1.1] x86/Documentation: Start documenting x86 topology
From: Borislav Petkov This should contain important aspects of how we represent the system topology on x86. If people have questions about it and this file doesn't answer it, then it must be updated. Signed-off-by: Borislav Petkov Cc: Thomas Gleixner --- Let me add a reference to the generic topology document Documentation/cputopology.txt too. Documentation/x86/topology.txt | 212 + 1 file changed, 212 insertions(+) create mode 100644 Documentation/x86/topology.txt diff --git a/Documentation/x86/topology.txt b/Documentation/x86/topology.txt new file mode 100644 index ..75021f128848 --- /dev/null +++ b/Documentation/x86/topology.txt @@ -0,0 +1,212 @@ +x86 Topology + + +This documents and clarifies the main aspects of x86 topology modelling +and representation in the kernel. Update/change when doing changes to +the respective code. + +The architecture-agnostic topology definitions are in +Documentation/cputopology.txt. This file holds x86-specific +differences/specialities which must not necessarily apply to the generic +definitions. Thus, the way to read up on Linux topology on x86 is to +start with the generic one and look at this one in parallel for the x86 +specifics. + +Needless to say, code should use the generic functions - this file is +*only* here to *document* the inner workings of x86 topology. + +Started by Thomas Gleixner and Borislav Petkov . + +The main aim of the topology facilities is to present adequate +interfaces to code which needs to know/query/use the structure of the +running system wrt threads, cores, packages, etc. + +The kernel does not care about the concept of physical sockets because +a socket has no relevance to software. It's an electromechanical +component. In the past a socket always contained a single package +(see below), but with the advent of Multi Chip Modules (MCM) a socket +can hold more than one package. So there might be still references to +sockets in the code, but they are of historical nature and should be +cleaned up. + +The topology of a system is described in the units of: + +- packages +- cores +- threads + +* Package: + + Packages contain a number of cores plus shared resources, e.g. DRAM + controller, shared caches etc. + + AMD nomenclature for package is 'Node'. + + Package-related topology information in the kernel: + + - cpuinfo_x86.x86_max_cores: + +The number of cores in a package. This information is retrieved via CPUID. + + - cpuinfo_x86.phys_proc_id: + +The physical ID of the package. This information is retrieved via CPUID +and deduced from the APIC IDs of the cores in the package. + + - cpuinfo_x86.logical_id: + +The logical ID of the package. As we do not trust BIOSes to enumerate the +packages in a consistent way, we introduced the concept of logical package +ID so we can sanely calculate the number of maximum possible packages in +the system and have the packages enumerated linearly. + + - topology_max_packages(): + +The maximum possible number of packages in the system. Helpful for per +package facilities to preallocate per package information. + + +* Cores: + + A core consists of 1 or more threads. It does not matter whether the threads + are SMT- or CMT-type threads. + + AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses + "core". + + Core-related topology information in the kernel: + + - smp_num_siblings: + +The number of threads in a core. The number of threads in a package can be +calculated by: + + threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings + + +* Threads: + + A thread is a single scheduling unit. It's the equivalent to a logical Linux + CPU. + + AMDs nomenclature for CMT threads is "Compute Unit Core". The kernel always + uses "thread". + + Thread-related topology information in the kernel: + + - topology_core_cpumask(): + +The cpumask contains all online threads in the package to which a thread +belongs. + +The number of online threads is also printed in /proc/cpuinfo "siblings." + + - topology_sibling_mask(): + +The cpumask contains all online threads in the core to which a thread +belongs. + + - topology_logical_package_id(): + +The logical package ID to which a thread belongs. + + - topology_physical_package_id(): + +The physical package ID to which a thread belongs. + + - topology_core_id(); + +The ID of the core to which a thread belongs. It is also printed in /proc/cpuinfo +"core_id." + + + +System topology examples + +Note: + +The alternative Linux CPU enumeration depends on how the BIOS enumerates the +threads. Many BIOSes enumerate all threads 0 first and then all threads 1. +That has the "advantage" that the logical Linux CPU numbers of threads 0 stay +the same whether threads are enabled or not. That's merely an implementation +detail and has no practical impact. + +1) Single Pac
Re: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger handler
On 24/03/16 09:29, Irina Tirdea wrote:
> Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> enable/disable the bus at each i2c transfer and must wait for
> the enable/disable to happen before sending the data.
>
> When reading data in the trigger handler, the bmc150 accel driver does
> one bus transfer for each axis. This has an impact on the frequency
> of the accelerometer at high sample rates due to additional delays
> introduced by the bus at each transfer.
>
> Reading all axis values in one bus transfer reduces the delays
> introduced by the bus.
>
> Signed-off-by: Irina Tirdea
I forgot to highlight on the earlier driver that there is also 'technically'
a bit of an ABI change here because we are now exporting as LE rather than CPU
order. However, I 'hope' anyone actually accessing the buffered data is either
doing it through a nice library or hasn't hacked the endian unwinding out of
the generic_buffer example!
Again, fingers crossed this doesn't break anything significant.
Applied,
Thanks,
Jonathan
> ---
> drivers/iio/gyro/bmg160_core.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> index 8d6e5b1..43570b8 100644
> --- a/drivers/iio/gyro/bmg160_core.c
> +++ b/drivers/iio/gyro/bmg160_core.c
> @@ -734,6 +734,7 @@ static const struct iio_event_spec bmg160_event = {
> .sign = 's',\
> .realbits = 16, \
> .storagebits = 16, \
> + .endianness = IIO_LE, \
> }, \
> .event_spec = &bmg160_event,\
> .num_event_specs = 1\
> @@ -773,20 +774,14 @@ static irqreturn_t bmg160_trigger_handler(int irq, void
> *p)
> struct iio_poll_func *pf = p;
> struct iio_dev *indio_dev = pf->indio_dev;
> struct bmg160_data *data = iio_priv(indio_dev);
> - int bit, ret, i = 0;
> - unsigned int val;
> + int ret;
>
> mutex_lock(&data->mutex);
> - for (bit = 0; bit < AXIS_MAX; bit++) {
> - ret = regmap_bulk_read(data->regmap, BMG160_AXIS_TO_REG(bit),
> -&val, 2);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - goto err;
> - }
> - data->buffer[i++] = ret;
> - }
> + ret = regmap_bulk_read(data->regmap, BMG160_REG_XOUT_L,
> +data->buffer, AXIS_MAX * 2);
> mutex_unlock(&data->mutex);
> + if (ret < 0)
> + goto err;
>
> iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> pf->timestamp);
>
Re: [PATCH 5/6] iio: accel: kxcjk-1013: use available_scan_masks
On 24/03/16 09:29, Irina Tirdea wrote:
> From: Adriana Reus
>
> Use available_scan_masks to allow the iio core to select
> the data to send to userspace depending on which axes are
> enabled, instead of doing this in the driver's interrupt
> handler.
>
> Signed-off-by: Adriana Reus
> Signed-off-by: Irina Tirdea
> Acked-by: Jonathan Cameron
> Acked-by: Srinivas Pandruvada
Applied, thanks,
Jonathan
> ---
> drivers/iio/accel/kxcjk-1013.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index edec1d0..3861fe9 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -115,6 +115,7 @@ enum kxcjk1013_axis {
> AXIS_X,
> AXIS_Y,
> AXIS_Z,
> + AXIS_MAX,
> };
>
> enum kxcjk1013_mode {
> @@ -953,6 +954,8 @@ static const struct iio_info kxcjk1013_info = {
> .driver_module = THIS_MODULE,
> };
>
> +static const unsigned long kxcjk1013_scan_masks[] = {0x7, 0};
> +
> static irqreturn_t kxcjk1013_trigger_handler(int irq, void *p)
> {
> struct iio_poll_func *pf = p;
> @@ -962,8 +965,7 @@ static irqreturn_t kxcjk1013_trigger_handler(int irq,
> void *p)
>
> mutex_lock(&data->mutex);
>
> - for_each_set_bit(bit, indio_dev->active_scan_mask,
> - indio_dev->masklength) {
> + for (bit = 0; bit < AXIS_MAX; bit++) {
> ret = kxcjk1013_get_acc_reg(data, bit);
> if (ret < 0) {
> mutex_unlock(&data->mutex);
> @@ -1204,6 +1206,7 @@ static int kxcjk1013_probe(struct i2c_client *client,
> indio_dev->dev.parent = &client->dev;
> indio_dev->channels = kxcjk1013_channels;
> indio_dev->num_channels = ARRAY_SIZE(kxcjk1013_channels);
> + indio_dev->available_scan_masks = kxcjk1013_scan_masks;
> indio_dev->name = name;
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &kxcjk1013_info;
>
Re: [PATCH 6/6] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
On 24/03/16 09:29, Irina Tirdea wrote:
> From: Adriana Reus
>
> Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> enable/disable the bus at each i2c transfer and must wait for
> the enable/disable to happen before sending the data.
>
> When reading data in the trigger handler, the kxcjk-1013 accel driver
> does one i2c transfer for each axis. This has an impact on the
> frequency of the accelerometer at high sample rates due to additional
> delays introduced by the i2c bus at each transfer.
>
> Reading all axis values in one i2c transfer reduces the delays
> introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
> that will fallback to reading each axis as a separate word in case i2c
> block read is not supported.
>
> Signed-off-by: Adriana Reus
> Signed-off-by: Irina Tirdea
> Acked-by: Jonathan Cameron
> Acked-by: Srinivas Pandruvada
Applied - with all the others to the togreg branch of iio.git - initially
pushed out
as testing for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/kxcjk-1013.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index 3861fe9..4881856 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -923,7 +923,7 @@ static const struct iio_event_spec kxcjk1013_event = {
> .realbits = 12, \
> .storagebits = 16, \
> .shift = 4, \
> - .endianness = IIO_CPU, \
> + .endianness = IIO_LE, \
> }, \
> .event_spec = &kxcjk1013_event, \
> .num_event_specs = 1\
> @@ -961,19 +961,16 @@ static irqreturn_t kxcjk1013_trigger_handler(int irq,
> void *p)
> struct iio_poll_func *pf = p;
> struct iio_dev *indio_dev = pf->indio_dev;
> struct kxcjk1013_data *data = iio_priv(indio_dev);
> - int bit, ret, i = 0;
> + int ret;
>
> mutex_lock(&data->mutex);
> -
> - for (bit = 0; bit < AXIS_MAX; bit++) {
> - ret = kxcjk1013_get_acc_reg(data, bit);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - goto err;
> - }
> - data->buffer[i++] = ret;
> - }
> + ret = i2c_smbus_read_i2c_block_data_or_emulated(data->client,
> + KXCJK1013_REG_XOUT_L,
> + AXIS_MAX * 2,
> + (u8 *)data->buffer);
> mutex_unlock(&data->mutex);
> + if (ret < 0)
> + goto err;
>
> iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> data->timestamp);
>
RE: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
Hi, > Sent: Monday, March 28, 2016 5:30 PM > > Hi, > > Yoshihiro Shimoda writes: > >> > ps: there might be bugs there, but it's a holiday and I really shouldn't > >> > be spending time on this right now ;-) > >> > >> I'm also off on holiday now until Sunday 10th April... yay :-) > >> > > >> > Anyway, have fun testing. Let me know if it doesn't work. > >> > >> I only have access to STi platforms which were broken by this change. > >> Not any of the platforms which rely on the functionality which > >> was introduced (although I can't see any reason why your patch wouldn't > >> work). > >> > >> Maybe Yoshihiro (on CC) could test this on the Renesas platforms and > >> confirm? > > > > Thank you for sending the email to me on CC. > > > > I tested Felipe's patch on Renesas platfroms (R-Car Gen2 and Gen3) and > > I fixed the patch like the following. > > > > However, my fixes patch might need to clean the code up more. > > > > Changes from Felipe's patch: > > - Change function names of xhci_rcar_init_quirk() to xhci_rcar_setup_quirk() > > I'm not sure renaming that function fits on the same patch ;-) Sounds > like it should be a separate patch altogether. I'll work on this > tomorrow if it's okay for you guys to test on your respective platforms :-) Thank you for the comment! I also think it should be separate patch ;) Also I'm okay to test your patch(es) on my platforms :) Best regards, Yoshihiro Shimoda > -- > balbi
Re: [PATCH 1/1] iio: fix config watermark initial value
On 24/03/16 09:23, Lars-Peter Clausen wrote:
> On 03/24/2016 10:09 AM, Irina Tirdea wrote:
>> config structure is set to 0 when updating the buffers, so by
>> default config->watermark will be 0. When computing the minimum
>> between config->watermark and the buffer->watermark or
>> insert_buffer-watermark, this will always be 0 regardless of the
>> value set by the user for the buffer.
>>
>> Set as initial value for config->watermark the maximum allowed
>> value so that the minimum value will always be set from one of the
>> buffers.
>>
>> Signed-off-by: Irina Tirdea
>
> Looks good. This bug was my fault, sorry.
>
> Fixes: f0566c0c405d ("iio: Set device watermark based on watermark of all
> attached buffers")
Applied to the fixes-togreg-post-rc1 branch of iio.git and marked for stable.
Thanks,
Jonathan
>
>> ---
>> drivers/iio/industrialio-buffer.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/iio/industrialio-buffer.c
>> b/drivers/iio/industrialio-buffer.c
>> index b976332..90462fc 100644
>> --- a/drivers/iio/industrialio-buffer.c
>> +++ b/drivers/iio/industrialio-buffer.c
>> @@ -653,6 +653,7 @@ static int iio_verify_update(struct iio_dev *indio_dev,
>> unsigned int modes;
>>
>> memset(config, 0, sizeof(*config));
>> +config->watermark = ~0;
>>
>> /*
>> * If there is just one buffer and we are removing it there is nothing
>>
>
Re: [PATCH 1/1] iio: remove unused gpio consumer.h include
On 24/03/16 09:08, Irina Tirdea wrote:
> GPIO handling code has been removed from the drivers (since
> this is now handled by the ACPI core) in commit 0f0796509c07 ("iio:
> remove gpio interrupt probing from drivers that use a single interrupt").
>
> Remove the include for linux/gpio/consumer.h since it is no longer
> used.
>
> Signed-off-by: Irina Tirdea
oops and good spot!
Applied to the togreg branch of iio.git
Thanks,
Jonathan
> ---
> drivers/iio/accel/bmc150-accel-core.c | 1 -
> drivers/iio/accel/kxcjk-1013.c | 1 -
> drivers/iio/accel/mma9553.c| 1 -
> drivers/iio/accel/stk8312.c| 1 -
> drivers/iio/accel/stk8ba50.c | 1 -
> drivers/iio/imu/kmx61.c| 1 -
> drivers/iio/light/stk3310.c| 1 -
> drivers/iio/magnetometer/bmc150_magn.c | 1 -
> 8 files changed, 8 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c
> b/drivers/iio/accel/bmc150-accel-core.c
> index feff894..65966e5 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index edec1d0..47305dc 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -20,7 +20,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/accel/mma9553.c b/drivers/iio/accel/mma9553.c
> index fa7d362..bb05f3e 100644
> --- a/drivers/iio/accel/mma9553.c
> +++ b/drivers/iio/accel/mma9553.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/accel/stk8312.c b/drivers/iio/accel/stk8312.c
> index 85fe7f7..e31023d 100644
> --- a/drivers/iio/accel/stk8312.c
> +++ b/drivers/iio/accel/stk8312.c
> @@ -11,7 +11,6 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/accel/stk8ba50.c b/drivers/iio/accel/stk8ba50.c
> index 5709d9e..300d955 100644
> --- a/drivers/iio/accel/stk8ba50.c
> +++ b/drivers/iio/accel/stk8ba50.c
> @@ -11,7 +11,6 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index e5306b4..2e7dd57 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -14,7 +14,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index 42d334b..9e847f8 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -16,7 +16,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/drivers/iio/magnetometer/bmc150_magn.c
> b/drivers/iio/magnetometer/bmc150_magn.c
> index ffcb75e..0e9da18 100644
> --- a/drivers/iio/magnetometer/bmc150_magn.c
> +++ b/drivers/iio/magnetometer/bmc150_magn.c
> @@ -23,7 +23,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
>
Re: [PATCH 1/1] iio: remove gpio interrupt probing from drivers that use a single interrupt
On 24/03/16 09:05, Irina Tirdea wrote:
> Commit 845c877009cf014b ("i2c / ACPI: Assign IRQ for devices that have
> GpioInt automatically") automatically assigns the first ACPI GPIO
> interrupt in client->irq, so we can remove the probing code from
> drivers that use only one interrupt.
>
> Commit 0f0796509c07c1c7 ("iio: remove gpio interrupt probing from drivers
> that use a single interrupt") removes gpio interrupt probing from most
> drivers. This patch cleans the remaining ones.
>
> Signed-off-by: Irina Tirdea
Applied to the togreg branch of iio.git, initially pushed out as testing
for the autobuilders to play with it.
Thanks. Good to get the last? of these cleaned up.
Jonathan
> ---
> drivers/iio/accel/mxc4005.c| 29 -
> drivers/iio/gyro/bmg160_core.c | 28
> 2 files changed, 57 deletions(-)
>
> diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
> index e72e218..c23f47a 100644
> --- a/drivers/iio/accel/mxc4005.c
> +++ b/drivers/iio/accel/mxc4005.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -380,31 +379,6 @@ static const struct iio_trigger_ops mxc4005_trigger_ops
> = {
> .owner = THIS_MODULE,
> };
>
> -static int mxc4005_gpio_probe(struct i2c_client *client,
> - struct mxc4005_data *data)
> -{
> - struct device *dev;
> - struct gpio_desc *gpio;
> - int ret;
> -
> - if (!client)
> - return -EINVAL;
> -
> - dev = &client->dev;
> -
> - gpio = devm_gpiod_get_index(dev, "mxc4005_int", 0, GPIOD_IN);
> - if (IS_ERR(gpio)) {
> - dev_err(dev, "failed to get acpi gpio index\n");
> - return PTR_ERR(gpio);
> - }
> -
> - ret = gpiod_to_irq(gpio);
> -
> - dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
> -
> - return ret;
> -}
> -
> static int mxc4005_chip_init(struct mxc4005_data *data)
> {
> int ret;
> @@ -470,9 +444,6 @@ static int mxc4005_probe(struct i2c_client *client,
> return ret;
> }
>
> - if (client->irq < 0)
> - client->irq = mxc4005_gpio_probe(client, data);
> -
> if (client->irq > 0) {
> data->dready_trig = devm_iio_trigger_alloc(&client->dev,
> "%s-dev%d",
> diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> index bbce3b0..822767c 100644
> --- a/drivers/iio/gyro/bmg160_core.c
> +++ b/drivers/iio/gyro/bmg160_core.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -31,7 +30,6 @@
> #include "bmg160.h"
>
> #define BMG160_IRQ_NAME "bmg160_event"
> -#define BMG160_GPIO_NAME "gpio_int"
>
> #define BMG160_REG_CHIP_ID 0x00
> #define BMG160_CHIP_ID_VAL 0x0F
> @@ -955,29 +953,6 @@ static const struct iio_buffer_setup_ops
> bmg160_buffer_setup_ops = {
> .postdisable = bmg160_buffer_postdisable,
> };
>
> -static int bmg160_gpio_probe(struct bmg160_data *data)
> -
> -{
> - struct device *dev;
> - struct gpio_desc *gpio;
> -
> - dev = data->dev;
> -
> - /* data ready gpio interrupt pin */
> - gpio = devm_gpiod_get_index(dev, BMG160_GPIO_NAME, 0, GPIOD_IN);
> - if (IS_ERR(gpio)) {
> - dev_err(dev, "acpi gpio get index failed\n");
> - return PTR_ERR(gpio);
> - }
> -
> - data->irq = gpiod_to_irq(gpio);
> -
> - dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio),
> - data->irq);
> -
> - return 0;
> -}
> -
> static const char *bmg160_match_acpi_device(struct device *dev)
> {
> const struct acpi_device_id *id;
> @@ -1022,9 +997,6 @@ int bmg160_core_probe(struct device *dev, struct regmap
> *regmap, int irq,
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &bmg160_info;
>
> - if (data->irq <= 0)
> - bmg160_gpio_probe(data);
> -
> if (data->irq > 0) {
> ret = devm_request_threaded_irq(dev,
> data->irq,
>
Re: [PATCH] sbs-battery: fix power status when battery is dry
+Rhyland Klein who original wrote this code...
On Mon, Mar 28, 2016 at 10:32 AM, YH Huang wrote:
>
> On Fri, 2016-03-25 at 11:06 +0800, Daniel Kurtz wrote:
> > On Thu, Mar 24, 2016 at 2:43 PM, YH Huang wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Thu, 2016-03-24 at 12:01 +0800, Daniel Kurtz wrote:
> > > > Hi YH,
> > > >
> > > > On Wed, Mar 23, 2016 at 5:53 PM, YH Huang wrote:
> > > > > When the battery is dry and BATTERY_FULL_DISCHARGED is set,
> > > > > we should check BATTERY_DISCHARGING to decide the power status.
> > > > > If BATTERY_DISCHARGING is set, the power status is not charging.
> > > > > Or the power status should be charging.
> > > > >
> > > > > Signed-off-by: YH Huang
> > > > > ---
> > > > > drivers/power/sbs-battery.c | 22 --
> > > > > 1 file changed, 12 insertions(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/drivers/power/sbs-battery.c b/drivers/power/sbs-battery.c
> > > > > index d6226d6..d86db0e 100644
> > > > > --- a/drivers/power/sbs-battery.c
> > > > > +++ b/drivers/power/sbs-battery.c
> > > > > @@ -382,11 +382,12 @@ static int sbs_get_battery_property(struct
> > > > > i2c_client *client,
> > > > >
> > > > > if (ret & BATTERY_FULL_CHARGED)
> > > > > val->intval = POWER_SUPPLY_STATUS_FULL;
> > > > > - else if (ret & BATTERY_FULL_DISCHARGED)
> > > > > - val->intval =
> > > > > POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > > > - else if (ret & BATTERY_DISCHARGING)
> > > > > - val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> > > > > - else
> > > > > + else if (ret & BATTERY_DISCHARGING) {
> > > > > + if (ret & BATTERY_FULL_DISCHARGED)
> > > > > + val->intval =
> > > > > POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > > > + else
> > > > > + val->intval =
> > > > > POWER_SUPPLY_STATUS_DISCHARGING;
> > > > > + } else
> > > >
> > > >
> > > > I think (BATTERY_DISCHARGING && BATTERY_FULL_DISCHARGED) is still
> > > > POWER_SUPPLY_STATUS_DISCHARGING.
> > > > So, let's just report what the battery says and do:
> > > >
> > > >else if (ret & BATTERY_DISCHARGING)
> > > >val->intval =
> > > > POWER_SUPPLY_STATUS_DISCHARGING;
> > > >
> > > So we just ignore the special situation (BATTERY_DISCHARGING &&
> > > BATTERY_FULL_DISCHARGED).
> > > Isn't POWER_SUPPLY_STATUS_NOT_CHARGING a useful information?
> >
> > The battery is discharging. The fact that it is also reporting that
> > it is already "discharged" just seems premature. I would expect to
> > only see NOT_CHARGING if completely discharged *and* not discharging.
>
> I check the "Smart Battery Data Specification Revision 1.1".
> And there are some words about FULLY_DISCHARGED.
> "Discharge should be stopped soon."
> "This status bit may be set prior to the
> ‘TERMINATE_DISCHARGE_ALARM’ as an early or first level warning of end of
> battery charge."
> It looks like the FULLY_DISCHARGED status is used to announce the
> warning of battery charge and it is still discharging if there is no one
> takes care of it.
Sure, it is in the sbs spec. That is why the battery is setting that bit.
The problem isn't with what the battery is doing, the issue here is in
how the kernel is interpreting it, and what it is choosing to expose
to user space.
It looks like the current property interface is not able to accurately
report the full status of the battery: "discharging & nearly empty".
Instead, IMHO, the closest it can report is that it is still
discharging (== POWER_SUPPLY_STATUS_DISCHARGING), and use some other
mechanism to report how much charge is actually left.
Re-using "POWER_SUPPLY_STATUS_NOT_CHARGING" to report "discharging &
nearly empty" seems arbitrary, wrong and unnecessary.
Of course, this bit of code is very old, as it was added in the
original TI BQ20Z75 gas gauge patch:
commit d3ab61ecbab2b8950108b3541bc9eda515d605e0
Author: Rhyland Klein
Date: Tue Sep 21 15:33:55 2010 -0700
bq20z75: Add support for more power supply properties
So, it would be nice if an sbs battery expert could chime in here,
since I don't really know what I am talking about, I am just
interpreting #define names.
-Dan
Re: [PATCH 1/1] iio: accel: bmc150: remove unused definition
On 24/03/16 09:00, Irina Tirdea wrote:
> bmc150_i2c_regmap_conf is defined in bmc150-accel-core.c, but
> never used here. The definition is needed in bmc150-accel-i2c.c,
> where it is again defined.
>
> Remove the unnecessary definition of bmc150_i2c_regmap_conf from
> bmc150-accel-core.c and update the one from bmc150-accel-i2c.c
> to contain all fields.
>
> Signed-off-by: Irina Tirdea
Silly question. Why isn't it shared between the i2c and spi drivers?
Looks to be the same in both cases (as we'd expect from regmap most
of the time!). I think it would be better to share it.
Jonathan
> ---
> drivers/iio/accel/bmc150-accel-core.c | 6 --
> drivers/iio/accel/bmc150-accel-i2c.c | 1 +
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c
> b/drivers/iio/accel/bmc150-accel-core.c
> index c73331f7..feff894 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -246,12 +246,6 @@ static const struct {
> {50, BMC150_ACCEL_SLEEP_500_MS},
> {100, BMC150_ACCEL_SLEEP_1_SEC} };
>
> -static const struct regmap_config bmc150_i2c_regmap_conf = {
> - .reg_bits = 8,
> - .val_bits = 8,
> - .max_register = 0x3f,
> -};
> -
> static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
>enum bmc150_power_modes mode,
>int dur_us)
> diff --git a/drivers/iio/accel/bmc150-accel-i2c.c
> b/drivers/iio/accel/bmc150-accel-i2c.c
> index b41404b..f0969fe 100644
> --- a/drivers/iio/accel/bmc150-accel-i2c.c
> +++ b/drivers/iio/accel/bmc150-accel-i2c.c
> @@ -31,6 +31,7 @@
> static const struct regmap_config bmc150_i2c_regmap_conf = {
> .reg_bits = 8,
> .val_bits = 8,
> + .max_register = 0x3f,
> };
>
> static int bmc150_accel_probe(struct i2c_client *client,
>
[PATCH] openvswitch: Use proper buffer size in nla_memcpy
For the input parameter count, it's better to use the size of destination buffer size, as nla_memcpy would take into account the length of the source netlink attribute when a data is copied from an attribute. Signed-off-by: Haishuang Yan --- net/openvswitch/conntrack.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c index dc5eb29..f8a8d43 100644 --- a/net/openvswitch/conntrack.c +++ b/net/openvswitch/conntrack.c @@ -968,7 +968,8 @@ static int parse_nat(const struct nlattr *attr, break; case OVS_NAT_ATTR_IP_MIN: - nla_memcpy(&info->range.min_addr, a, nla_len(a)); + nla_memcpy(&info->range.min_addr, a, + sizeof(info->range.min_addr)); info->range.flags |= NF_NAT_RANGE_MAP_IPS; break; -- 1.8.3.1
Re: [PATCH v6 2/6] power-domain: allow domains only handling idle requests
Am Donnerstag, 10. März 2016, 05:22:54 schrieb Elaine Zhang: > On some Rockchip SoC there exist child-domains only handling their > idle state with the actual power-state handled by a parent-domain. > > So allow such types of domains. For them, we can determine their > state (on/of) by checking the inverse idle-state instead. > > There exist one special case if both idle as well power handling > were set as not present, but as the domain-data is defined in the > code itself, we can expect the reasonable developer to define them > > So allow such types of domains. For them, we can determine their > state (on/of) by checking the inverse idle-state instead. > > There exist one special case if both idle as well power handling > were set as not present, but as the domain-data is defined in the > code itself, we can expect the reasonable developer to define them > in a correct, without adding more checks. > > Signed-off-by: Elaine Zhang applied to my armsoc/drivers branch for 4.7 Thanks Heiko
Re: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger handler
> > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > enable/disable the bus at each i2c transfer and must wait for
> > the enable/disable to happen before sending the data.
> >
> > When reading data in the trigger handler, the bmc150 accel driver does
should refer to bmg160
> > one bus transfer for each axis. This has an impact on the frequency
> > of the accelerometer at high sample rates due to additional delays
> > introduced by the bus at each transfer.
> >
> > Reading all axis values in one bus transfer reduces the delays
> > introduced by the bus.
> >
> > Signed-off-by: Irina Tirdea
> I forgot to highlight on the earlier driver that there is also 'technically'
> a bit of an ABI change here because we are now exporting as LE rather than CPU
> order. However, I 'hope' anyone actually accessing the buffered data is
> either
> doing it through a nice library or hasn't hacked the endian unwinding out of
> the generic_buffer example!
the patch takes away the possibility to do buffered reads on individual
channels (not sure if this is useful per se)
this optimizes for the common case, ok;
wondering if adding
.endianness = IIO_LE
is actually an unrelated fix
> Again, fingers crossed this doesn't break anything significant.
>
> Applied,
>
> Thanks,
>
> Jonathan
> > ---
> > drivers/iio/gyro/bmg160_core.c | 17 ++---
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> > index 8d6e5b1..43570b8 100644
> > --- a/drivers/iio/gyro/bmg160_core.c
> > +++ b/drivers/iio/gyro/bmg160_core.c
> > @@ -734,6 +734,7 @@ static const struct iio_event_spec bmg160_event = {
> > .sign = 's',\
> > .realbits = 16, \
> > .storagebits = 16, \
> > + .endianness = IIO_LE, \
> > }, \
> > .event_spec = &bmg160_event,\
> > .num_event_specs = 1\
> > @@ -773,20 +774,14 @@ static irqreturn_t bmg160_trigger_handler(int irq,
> > void *p)
> > struct iio_poll_func *pf = p;
> > struct iio_dev *indio_dev = pf->indio_dev;
> > struct bmg160_data *data = iio_priv(indio_dev);
> > - int bit, ret, i = 0;
> > - unsigned int val;
> > + int ret;
> >
> > mutex_lock(&data->mutex);
> > - for (bit = 0; bit < AXIS_MAX; bit++) {
> > - ret = regmap_bulk_read(data->regmap, BMG160_AXIS_TO_REG(bit),
> > - &val, 2);
> > - if (ret < 0) {
> > - mutex_unlock(&data->mutex);
> > - goto err;
> > - }
> > - data->buffer[i++] = ret;
> > - }
> > + ret = regmap_bulk_read(data->regmap, BMG160_REG_XOUT_L,
> > + data->buffer, AXIS_MAX * 2);
> > mutex_unlock(&data->mutex);
> > + if (ret < 0)
> > + goto err;
> >
> > iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> >pf->timestamp);
> >
>
--
Peter Meerwald-Stadler
+43-664-218 (mobile)
Re: [PATCH v6 1/6] rockchip: power-domain: make idle handling optional
Am Donnerstag, 10. März 2016, 05:22:53 schrieb Elaine Zhang: > Not all new socs need to handle idle states on domain state changes, > so add the possibility to make them optional. > > Signed-off-by: Elaine Zhang applied to my armsoc/drivers branch for 4.7 Thanks Heiko
[PATCH][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT
Signed-off-by: Wang Nan --- man2/perf_event_open.2 | 11 +++ 1 file changed, 11 insertions(+) diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2 index c90fc51..b232cba 100644 --- a/man2/perf_event_open.2 +++ b/man2/perf_event_open.2 @@ -2719,6 +2719,17 @@ The argument is a BPF program file descriptor that was created by a previous .BR bpf (2) system call. +.TP +.BR PERF_EVENT_IOC_PAUSE_OUTPUT " (since Linux 4.6)" +.\" commit ? (http://lkml.kernel.org/g/1459147292-239310-2-git-send-email-wangn...@huawei.com) +This allows pausing and resuming the event's ring-buffer. A +paused ring-buffer does not prevent samples generation, but simply +discards them. The discarded samples are considered lost, causes +.BR PERF_RECORD_LOST +to be generated when possible. + +The argument is an integer. Nonzero value pauses the ring-buffer, +zero value resumes the ring-buffer. .SS Using prctl A process can enable or disable all the event groups that are attached to it using the -- 1.8.3.4
[PATCH][manpages 2/2] perf_event_open.2: Document write_backward
Signed-off-by: Wang Nan
---
man2/perf_event_open.2 | 57 --
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index b232cba..942a410 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -234,8 +234,10 @@ struct perf_event_attr {
mmap2 : 1, /* include mmap with inode data */
comm_exec : 1, /* flag comm events that are due to exec */
use_clockid: 1, /* use clockid for time fields */
+ context_switch : 1, /* context switch data */
+ write_backward : 1, /* Write ring buffer from end to beginning */
- __reserved_1 : 38;
+ __reserved_1 : 36;
union {
__u32 wakeup_events;/* wakeup every n events */
@@ -1105,6 +1107,30 @@ field.
This can make it easier to correlate perf sample times with
timestamps generated by other tools.
.TP
+.IR "write_backward" " (since Linux 4.6)"
+.\" commit ?
(http://lkml.kernel.org/g/1459147292-239310-5-git-send-email-wangn...@huawei.com)
+This makes the resuling event use a backward ring-buffer, which
+writes samples from the end of the ring-buffer.
+
+It is not allowed to connect events with backward and forward
+ring-buffer settings together using
+.B PERF_EVENT_IOC_SET_OUTPUT.
+
+Backward ring-buffer is useful when the ring-buffer is overwritable
+(created by readonly
+.BR mmap (2)
+). In this case,
+.IR data_tail
+is useless,
+.IR data_head
+points to the head of the most recent sample in a backward
+ring-buffer. It is easy to iterate over the whole ring-buffer by reading
+samples one by one because size of a sample can be found from decoding
+its header. In contract, in a forward overwritable ring-buffer, the only
+information is the end of the most recent sample which is pointed by
+.IR data_head,
+but the size of a sample can't be determined from the end of it.
+.TP
.IR "wakeup_events" ", " "wakeup_watermark"
This union sets how many samples
.RI ( wakeup_events )
@@ -1634,7 +1660,9 @@ And vice versa:
.TP
.I data_head
This points to the head of the data section.
-The value continuously increases, it does not wrap.
+The value continuously increases (or decrease if
+.IR write_backward
+is set), it does not wrap.
The value needs to be manually wrapped by the size of the mmap buffer
before accessing the samples.
@@ -2581,6 +2609,24 @@ Starting with Linux 3.18,
.B POLL_HUP
is indicated if the event being monitored is attached to a different
process and that process exits.
+.SS Reading from overwritable ring-buffer
+Reader is unable to update
+.IR data_tail
+if the mapping is not
+.BR PROT_WRITE .
+In this case, kernel will overwrite data without considering whether
+they are read or not, so ring-buffer is overwritable and
+behaves like a flight recorder. To read from an overwritable
+ring-buffer, setting
+.IR write_backward
+is suggested, or it would be hard to find a proper position to start
+decoding. In addition, ring-buffer should be paused before reading
+through
+.BR ioctl (2)
+with
+.B PERF_EVENT_IOC_PAUSE_OUTPUT
+to avoid racing between kernel and reader. Ring-buffer should be resumed
+after finish reading.
.SS rdpmc instruction
Starting with Linux 3.4 on x86, you can use the
.\" commit c7206205d00ab375839bd6c7ddb247d600693c09
@@ -2693,6 +2739,13 @@ The file descriptors must all be on the same CPU.
The argument specifies the desired file descriptor, or \-1 if
output should be ignored.
+
+Two events with different
+.IR write_backward
+settings are not allowed to be connected together using
+.B PERF_EVENT_IOC_SET_OUTPUT.
+.B EINVAL
+is returned in this case.
.TP
.BR PERF_EVENT_IOC_SET_FILTER " (since Linux 2.6.33)"
.\" commit 6fb2915df7f0747d9044da9dbff5b46dc2e20830
--
1.8.3.4
[PATCH net-next 0/2] net: hns: add setting coalescing parameters for HNS v2
There are some different REGs about coalescing setting between HNS V2 and HNS V1. The current HNS driver is only considering the situation for HNS V1. It needs to support both of them. And Ethtool needs to know if it is successful to set the parameters as well. The patchset as below: >from Lisheng, one fix about setting overtime regs, and the other is about the return value from HW when setting the parameters. Lisheng (2): net: hns: fixed the setting and getting overtime bug net: hns: set-coalesce-usecs returns errno by dsaf.ko drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +- drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 64 +++ drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 196 ++ drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 23 +-- drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 1 + drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 6 +- 6 files changed, 133 insertions(+), 159 deletions(-) -- 1.9.1
[PATCH net-next 2/2] net: hns: set-coalesce-usecs returns errno by dsaf.ko
From: Lisheng
It may fail to set coalesce usecs to HW, and Ethtool needs to know if it
is successful to cfg the parameter or not. So it needs return the errno by
dsaf.ko.
Signed-off-by: Lisheng
Signed-off-by: Yisen Zhuang
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 6 +++---
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 6 --
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 37d0cce..e8d36aa 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -469,7 +469,7 @@ struct hnae_ae_ops {
u32 *tx_usecs, u32 *rx_usecs);
void (*get_rx_max_coalesced_frames)(struct hnae_handle *handle,
u32 *tx_frames, u32 *rx_frames);
- void (*set_coalesce_usecs)(struct hnae_handle *handle, u32 timeout);
+ int (*set_coalesce_usecs)(struct hnae_handle *handle, u32 timeout);
int (*set_coalesce_frames)(struct hnae_handle *handle,
u32 coalesce_frames);
void (*set_promisc_mode)(struct hnae_handle *handle, u32 en);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 1dd1d69..a1cb461 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -469,13 +469,13 @@ static void hns_ae_get_rx_max_coalesced_frames(struct
hnae_handle *handle,
ring_pair->port_id_in_comm);
}
-static void hns_ae_set_coalesce_usecs(struct hnae_handle *handle,
- u32 timeout)
+static int hns_ae_set_coalesce_usecs(struct hnae_handle *handle,
+u32 timeout)
{
struct ring_pair_cb *ring_pair =
container_of(handle->qs[0], struct ring_pair_cb, q);
- (void)hns_rcb_set_coalesce_usecs(
+ return hns_rcb_set_coalesce_usecs(
ring_pair->rcb_common, ring_pair->port_id_in_comm, timeout);
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 9c3ba65..b138181 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -794,8 +794,10 @@ static int hns_set_coalesce(struct net_device *net_dev,
(!ops->set_coalesce_frames))
return -ESRCH;
- ops->set_coalesce_usecs(priv->ae_handle,
- ec->rx_coalesce_usecs);
+ ret = ops->set_coalesce_usecs(priv->ae_handle,
+ ec->rx_coalesce_usecs);
+ if (ret)
+ return ret;
ret = ops->set_coalesce_frames(
priv->ae_handle,
--
1.9.1
[PATCH net-next 1/2] net: hns: fixed the setting and getting overtime bug
From: Lisheng
The overtime setting and getting REGs in HNS V2 is defferent from HNS V1.
It needs to be distinguished between them if getting or setting the REGs.
Signed-off-by: Lisheng
Signed-off-by: Yisen Zhuang
---
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 60 +++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 196 ++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 23 +--
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 1 +
4 files changed, 126 insertions(+), 154 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 285c893..1dd1d69 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -159,11 +159,6 @@ struct hnae_handle *hns_ae_get_handle(struct hnae_ae_dev
*dev,
ae_handle->qs[i]->tx_ring.q = ae_handle->qs[i];
ring_pair_cb->used_by_vf = 1;
- if (port_idx < DSAF_SERVICE_PORT_NUM_PER_DSAF)
- ring_pair_cb->port_id_in_dsa = port_idx;
- else
- ring_pair_cb->port_id_in_dsa = 0;
-
ring_pair_cb++;
}
@@ -453,59 +448,46 @@ static int hns_ae_set_pauseparam(struct hnae_handle
*handle,
static void hns_ae_get_coalesce_usecs(struct hnae_handle *handle,
u32 *tx_usecs, u32 *rx_usecs)
{
- int port;
-
- port = hns_ae_map_eport_to_dport(handle->eport_id);
+ struct ring_pair_cb *ring_pair =
+ container_of(handle->qs[0], struct ring_pair_cb, q);
- *tx_usecs = hns_rcb_get_coalesce_usecs(
- hns_ae_get_dsaf_dev(handle->dev),
- hns_dsaf_get_comm_idx_by_port(port));
- *rx_usecs = hns_rcb_get_coalesce_usecs(
- hns_ae_get_dsaf_dev(handle->dev),
- hns_dsaf_get_comm_idx_by_port(port));
+ *tx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
+ *rx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
}
static void hns_ae_get_rx_max_coalesced_frames(struct hnae_handle *handle,
u32 *tx_frames, u32 *rx_frames)
{
- int port;
+ struct ring_pair_cb *ring_pair =
+ container_of(handle->qs[0], struct ring_pair_cb, q);
- assert(handle);
-
- port = hns_ae_map_eport_to_dport(handle->eport_id);
-
- *tx_frames = hns_rcb_get_coalesced_frames(
- hns_ae_get_dsaf_dev(handle->dev), port);
- *rx_frames = hns_rcb_get_coalesced_frames(
- hns_ae_get_dsaf_dev(handle->dev), port);
+ *tx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
+ *rx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
}
static void hns_ae_set_coalesce_usecs(struct hnae_handle *handle,
u32 timeout)
{
- int port;
+ struct ring_pair_cb *ring_pair =
+ container_of(handle->qs[0], struct ring_pair_cb, q);
- assert(handle);
-
- port = hns_ae_map_eport_to_dport(handle->eport_id);
-
- hns_rcb_set_coalesce_usecs(hns_ae_get_dsaf_dev(handle->dev),
- port, timeout);
+ (void)hns_rcb_set_coalesce_usecs(
+ ring_pair->rcb_common, ring_pair->port_id_in_comm, timeout);
}
static int hns_ae_set_coalesce_frames(struct hnae_handle *handle,
u32 coalesce_frames)
{
- int port;
- int ret;
+ struct ring_pair_cb *ring_pair =
+ container_of(handle->qs[0], struct ring_pair_cb, q);
- assert(handle);
-
- port = hns_ae_map_eport_to_dport(handle->eport_id);
-
- ret = hns_rcb_set_coalesced_frames(hns_ae_get_dsaf_dev(handle->dev),
- port, coalesce_frames);
- return ret;
+ return hns_rcb_set_coalesced_frames(
+ ring_pair->rcb_common,
+ ring_pair->port_id_in_comm, coalesce_frames);
}
void hns_ae_update_stats(struct hnae_handle *handle,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 1218880..28ee26e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -215,9 +215,9 @@ static void hns_rcb_ring_init(struct ring_pair_cb
*ring_pair, int ring_type)
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
bd_size_type);
dsaf_write_dev(q, RCB_RING_RX_RING
Re: ARC dw-mshc binding compat string
Hi,
On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
> Hi Marek, Vladimir,
>
> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 21:52, Marek Vasut wrote:
On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 20:10, Marek Vasut wrote:
>>
>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>
>>> Hi Marek,
>>>
>>> On 26.03.2016 19:30, Marek Vasut wrote:
On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 12:14, Marek Vasut wrote:
>>
>> Hi!
>>
>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix
>> in
>> the DT compatible string:
>>
>> mmc@0x15000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = < 0x15000 0x400 >;
>> num-slots = < 1 >;
>> fifo-depth = < 16 >;
>> card-detect-delay = < 200 >;
>> clocks = <&apbclk>, <&mmcclk>;
>> clock-names = "biu", "ciu";
>> interrupts = < 7 >;
>> bus-width = < 4 >;
>> };
>>
>> I don't think this is OK, since ARC is unrelated to Altera, which is
>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>> should be extended with another compatibility string, something like
>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>> accordingly. What do you think ?
>>
> There is "snps,dw-mshc" described in
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and
> supported by
> dw_mmc host controller driver.
Thanks, that's even better.
btw what do you think of using altr, prefix on non-altera system, that
doesn't seem ok, right ?
>>> according to ePAPR the prefix should represent a device (IP block here
>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>> non-Altera system, if Altera provides another hardware vendor with
>>> some own IP block.
>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>> chip makers (Altera etc).
> Correct.
>
>>
>>>
>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on
>>> description
>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc"
>>> seems
>>> to be redundant.
Yes..it's redundant..i should be combined to "snps,dw-mshc".
>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>> one needs it as well, but most likely yes.
>>
>> I wonder if that bit is needed on some particular version of the DWMMC
>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>> binding ? Or should we use DT property to discern the need for this bit ?
>>
> That's the most common way to take into account peculiarities, add
> a property and handle it from the driver.
And by "that" you mean which of those two I listed , the
"snps,dw-mshc-vN" or adding new DT prop ?
>>> I meant to add a new property, not a new compatible, but that's just
>>> my experience.
>>>
>>> Let me say it __might__ happen that a particular change you need is
>>> specific to a particular version of the DWMMC IP (query Synopsys
>>> by the way), but more probably it might be e.g. the same IP version with
>>> a different reduced or extended configuration or a minor fix/improvement
>>> to the IP block without resulting version number bump.
>>>
>>> For example I don't remember that errata fixes in IP blocks result in
>>> a new compatible, instead there are quite common optional "quirk"
>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>> Right, this very much matches how I see it as well. Thanks for confirming.
>>
>> Alexey, can you tell us if the requirement for setting
>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>> disappeared with some revision OR if this is some configuration
>> option of the core during synthesis ?
>
> Sorry for not following that discussion during my weekend but I'll try
> to address all questions now.
SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
But it's difficult to use the generic feature..because it's considered the
below things.
If Card is SDR50/SDR104/DDR50 mode..
1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit
is set to 0,
2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit
is set to 1,
If Card is SDR12/SDR25 mode, then
Re: [PATCH 0/4 v3] drm: Introduce drm_connector_register_all() helper
Hi Daniel, On Wed, 2016-03-23 at 11:37 +0100, Daniel Vetter wrote: > On Wed, Mar 23, 2016 at 11:42:53AM +0300, Alexey Brodkin wrote: > > > > As a pair to already existing drm_connector_unplug_all() > > (which we'll rename in this series to drm_connector_unregister_all()) > > we're adding generic implementation of what is already done in some drivers > > for registering all connectors. > > > > After implementation of that new helper we're updating 2 drivers > > that used to use it's own implementation: > > [1] atmel_hlcdc > > [2] rcar_du > > > > And one driver that uses unregister(): > > [1] udl > > > > Other drivers still use load() callback and so should be first modified so > > their load() gets called from their probe() explicitly. > > > > Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x > > board). > > > > Changes v2 -> v3: > > * Added acks for 1, 3 and 4 patches > > * Updated kerneldoc descriptins of both register_ and unregister_all() > > * Updated commit messages (mostly spellos and grammar issues) > > > > Changes v1 -> v2: > > * Rename drm_connector_unplug_all() to drm_connector_unregister_all() > > * Use drm_for_each_connector() instead of list_for_each_entry() > > * Updated kerneldoc for drm_dev_register() > > > > Alexey Brodkin (4): > > drm: Rename drm_connector_unplug_all() to > > drm_connector_unregister_all() > > drm: Introduce drm_connector_register_all() helper > > drm: atmel_hldc: Use generic drm_connector_register_all() helper > > drm: rcar-du: Use generic drm_connector_register_all() helper > lgtm overall, but merge window is happening so don't want to throw 4.7 > patches into drm-misc. So will let these soak for a while more, please > ping me after -rc1 is out that I don't forget them. As you asked I'm pinging you with request to apply that series. Also would be very nice if you take a look at that comment from David Herrmann before application of that series: http://article.gmane.org/gmane.comp.video.dri.devel/149708/match=re+patch+2+4+v3+drm+introduce+drm_connector_register_al l+helper -Alexey
Hello Dear
-- Hello Dear, My name is Cynthia, I got your email from Facebook and i will like you to contact me back at this email ( cynthiabikom...@gmail.com ) is very important. Yours Faithful Cynthia
Re: ARC dw-mshc binding compat string
Hi Jaehoon, On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote: > Hi, [snip] > > > > > > > > > > > > > > > > That said, I would rather prefer to see "snps,dw-mshc" prefix > > > > > > > > on description > > > > > > > > of an MMC controller found on SoCFPGA series, > > > > > > > > "altr,socfpga-dw-mshc" seems > > > > > > > > to be redundant. > Yes..it's redundant..i should be combined to "snps,dw-mshc". So for socfpga platform compat string should be something like "snps,dw-mshc-socfpga" then? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA > > > > > > > one > > > > > > > "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio > > > > > > > one > > > > > > > "img,pistachio-dw-mshc" need specialty bit > > > > > > > (SDMMC_CMD_USE_HOLD_REG), > > > > > > > while the stock one "snps,dw-mshc" does not. I am not sure if the > > > > > > > ARC > > > > > > > one needs it as well, but most likely yes. > > > > > > > > > > > > > > I wonder if that bit is needed on some particular version of the > > > > > > > DWMMC > > > > > > > core. In that case, should we have "snps,dw-mshc" and > > > > > > > "snps,dw-mshc-vN" > > > > > > > binding ? Or should we use DT property to discern the need for > > > > > > > this bit ? > > > > > > > > > > > > > That's the most common way to take into account peculiarities, add > > > > > > a property and handle it from the driver. > > > > > And by "that" you mean which of those two I listed , the > > > > > "snps,dw-mshc-vN" or adding new DT prop ? > > > > > > > > > I meant to add a new property, not a new compatible, but that's just > > > > my experience. > > > > > > > > Let me say it __might__ happen that a particular change you need is > > > > specific to a particular version of the DWMMC IP (query Synopsys > > > > by the way), but more probably it might be e.g. the same IP version with > > > > a different reduced or extended configuration or a minor fix/improvement > > > > to the IP block without resulting version number bump. > > > > > > > > For example I don't remember that errata fixes in IP blocks result in > > > > a new compatible, instead there are quite common optional "quirk" > > > > properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :) > > > Right, this very much matches how I see it as well. Thanks for confirming. > > > > > > Alexey, can you tell us if the requirement for setting > > > SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or > > > disappeared with some revision OR if this is some configuration > > > option of the core during synthesis ? > > Sorry for not following that discussion during my weekend but I'll try > > to address all questions now. > SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously. > But it's difficult to use the generic feature..because it's considered the > below things. > > If Card is SDR50/SDR104/DDR50 mode.. > 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit > is set to 0, > 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit > is set to 1, > If Card is SDR12/SDR25 mode, then this bit is set to 1. So card type is also important here and for certain card type we don't need to set SDMMC_CMD_USE_HOLD_REG, right? > We need to check phase shift scheme..but as i knew, each SoC have been > implemented differently for phase shift. > (Phase shift have dependency to SoC.) Given my assumption above we need to check 2 things: * Card type * SoC-specific implementation detail (phase shift scheme) > And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]). > (It described whether IP have hold register or not) Ah actually 3 things + IMPLEMENT_HOLD_REG > I didn't read this thread entirely. > I'm not sure what you have discussed..but my understanding is right..i > recommend to use "snps,dw-mshc" for ARC compat > string. > Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the > basic dw-mmc controller functionality. Hm, interesting looks like you already made some changes here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb7a933471f6413ca44dd36efd57f2fa9429 So now driver checks if SoC has HOLD REG then SDMMC_CMD_USE_HOLD_REG will be set (regardless card type). And what's interesting and connected to this discussion since mentioned commit there's no point in having both "altr,socfpga-dw-mshc" and "img,pistachio-dw-mshc" compat strings because the do nothing now. I.e. it's time to replace both mentioned compat strings with generic "snps,dw-mshc". Anybody volunteers for that .dts* cleanup? -Alexey
Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc
Thanks Arnaldo for putting the effort. I've tested this patch on powerpc and it looks fine to me. Please find my below comments. On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu: Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu: Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu: 'perf kvm record' is not available on powerpc because 'perf' relies on the 'cycles' event (a PMU event) to profile the guest. However, for powerpc, this can't be used from the host because the PMUs are controlled by the guest rather than the host. There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is hit whenever any of the threads exit the guest context. The guest instruction pointer dumped along with this tracepoint data in the field 'pc', can be used as guest instruction pointer. This patch changes default event as kvm_hv:kvm_guest_exit for recording guest data in host on powerpc. As we are using host event to record guest data, this approach will enable only --guest option of 'perf kvm'. Still --host --guest together won't work. It should, i.e. --host --guest should translate to: -e cycles:H,kvm_hv:kvm_guest_exit I.e. both collect cycles only in the host, and also the tracepoint that will allow us to get the guest approximation for the unavailable cycles event, no? I'm putting the infrastructure work needed for this the perf/cpumode branch. More work will be put there soon. So I took a different path and made perf_evsel__parse_sample set a new perf_sample.cpumode field, this way we'll end up having just to set a per-evsel ->post_parse_sample() callback for the event that replaces "cycles" for PPC guests where we'll just set data->ip and data->cpumode, the rest of the code remains unchanged. The changes I made looks useful in itself, as, IIRC more code was removed than added. I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for testing, that has: Ok, so the infrastructure got merged already and from there the next steps are in running with: perf kvm --guest record -a -e cycles:H,kvm:kvm_exit And then, with the patch below applied, try: perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report -i perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit The initial proposal was to change the default event as "kvm_guest_exit" for kvm recording/reporting on ppc. If I understand it correctly, your patch creates a handler for reporting kvm events based on "munge_ppc_guest_event" and the required tracepoint i.e., we need to mention the required tracepoint event name for recording and reporting. There might be a little bit of an issue here. For scripts which depend on generic perf kvm record/report, we need to change those appropriately to prevent those from failing on powerpc. Otherwise, (just a thought) can we create some kind of an alias to map the ppc specific perf kvm commands with the generic perf kvm. For e.g : perf kvm record -e "kvm_hv:kvm_guest_exit" mapped to perf kvm record & perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped to perf kvm report. Regards, Ravi
Re: [PATCH v6 3/6] rockchip: power-domain: add support for sub-power domains
Am Donnerstag, 10. März 2016, 05:22:55 schrieb Elaine Zhang:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences,
> which needs to have more than one power domain enabled to be operational.
>
> Signed-off-by: Elaine Zhang
applied to my armsoc/drivers branch for 4.7 [0] with some changes.
Please shout if things don't look right :-)
Apart from additional error outputs, I moved the of_put of parent in the
error case, as we shouldn't touch of_nodes we get as parameters. Instead
rockchip_pm_add_subdomain would already do that for subdomains and
rockchip_pm_domain_probe now also does it itself.
Also when rockchip_pm_add_subdomain for a sub-sub-domain fails
(in rockchip_pm_add_subdomain), we don't need to remove the parent
domain association, so I removed the return there.
Heiko
---
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 0181534..1fca9e5 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -380,10 +380,11 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu
*pmu,
for_each_child_of_node(parent, np) {
u32 idx;
- if (of_property_read_u32(parent, "reg", &idx)) {
+ error = of_property_read_u32(parent, "reg", &idx);
+ if (error) {
dev_err(pmu->dev,
- "%s: failed to retrieve domain id (reg)\n",
- parent->name);
+ "%s: failed to retrieve domain id (reg): %d\n",
+ parent->name, error);
goto err_out;
}
parent_domain = pmu->genpd_data.domains[idx];
@@ -395,17 +396,19 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu
*pmu,
goto err_out;
}
- if (of_property_read_u32(np, "reg", &idx)) {
+ error = of_property_read_u32(np, "reg", &idx);
+ if (error) {
dev_err(pmu->dev,
- "%s: failed to retrieve domain id (reg)\n",
- np->name);
+ "%s: failed to retrieve domain id (reg): %d\n",
+ np->name, error);
goto err_out;
}
child_domain = pmu->genpd_data.domains[idx];
- if (pm_genpd_add_subdomain(parent_domain, child_domain)) {
- dev_err(pmu->dev, "%s failed to add subdomain: %s\n",
- parent_domain->name, child_domain->name);
+ error = pm_genpd_add_subdomain(parent_domain, child_domain);
+ if (error) {
+ dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n",
+ parent_domain->name, child_domain->name, error);
goto err_out;
} else {
dev_dbg(pmu->dev, "%s add subdomain: %s\n",
@@ -414,16 +417,10 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu
*pmu,
- error = rockchip_pm_add_subdomain(pmu, np);
- if (error < 0)
- goto rm_sub_domain;
+ rockchip_pm_add_subdomain(pmu, np);
}
return 0;
err_out:
- of_node_put(parent);
of_node_put(np);
- return -EINVAL;
-rm_sub_domain:
- pm_genpd_remove_subdomain(parent_domain, child_domain);
return error;
}
@@ -498,6 +497,7 @@ static int rockchip_pm_domain_probe(struct platform_device
*pdev)
if (error < 0) {
dev_err(dev, "failed to handle subdomain node %s: %d\n",
node->name, error);
+ of_node_put(node);
goto err_out;
}
}
---
[0]
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.7-armsoc/drivers&id=6be05b5ec16132f3df3f1d857ab01e30f726b542
[PATCH] i40iw: pass hw_stats by reference rather than by value
From: Colin Ian King
passing hw_stats by value requires a 280 byte copy so instead
pass it by reference is much more efficient.
Signed-off-by: Colin Ian King
---
drivers/infiniband/hw/i40iw/i40iw_virtchnl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
index 6b68f78..62bb8265 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
@@ -254,7 +254,7 @@ static void vchnl_pf_send_get_hmc_fcn_resp(struct
i40iw_sc_dev *dev,
static void vchnl_pf_send_get_pe_stats_resp(struct i40iw_sc_dev *dev,
u32 vf_id,
struct i40iw_virtchnl_op_buf
*vchnl_msg,
- struct i40iw_dev_hw_stats hw_stats)
+ struct i40iw_dev_hw_stats *hw_stats)
{
enum i40iw_status_code ret_code;
u8 resp_buffer[sizeof(struct i40iw_virtchnl_resp_buf) + sizeof(struct
i40iw_dev_hw_stats) - 1];
@@ -264,7 +264,7 @@ static void vchnl_pf_send_get_pe_stats_resp(struct
i40iw_sc_dev *dev,
vchnl_msg_resp->iw_chnl_op_ctx = vchnl_msg->iw_chnl_op_ctx;
vchnl_msg_resp->iw_chnl_buf_len = sizeof(resp_buffer);
vchnl_msg_resp->iw_op_ret_code = I40IW_SUCCESS;
- *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = hw_stats;
+ *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = *hw_stats;
ret_code = dev->vchnl_if.vchnl_send(dev, vf_id, resp_buffer,
sizeof(resp_buffer));
if (ret_code)
i40iw_debug(dev, I40IW_DEBUG_VIRT,
@@ -541,7 +541,7 @@ enum i40iw_status_code i40iw_vchnl_recv_pf(struct
i40iw_sc_dev *dev,
devstat->ops.iw_hw_stat_read_all(devstat, &devstat->hw_stats);
spin_unlock_irqrestore(&dev->dev_pestat.stats_lock, flags);
vf_dev->msg_count--;
- vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg,
devstat->hw_stats);
+ vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg,
&devstat->hw_stats);
break;
default:
i40iw_debug(dev, I40IW_DEBUG_VIRT,
--
2.7.4
Re: [PATCH v6 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain
Am Donnerstag, 10. März 2016, 05:22:56 schrieb Elaine Zhang: > According to a description from TRM, add all the power domains > > Signed-off-by: Elaine Zhang applied for 4.7 Thanks Heiko
Re: [PATCH v6 5/6] dt/bindings: rockchip: modify document of Rockchip power domains
Am Donnerstag, 10. März 2016, 05:24:21 schrieb Elaine Zhang: > Add binding documentation for the power domains > found on Rockchip RK3399 SoCs > > Signed-off-by: Elaine Zhang applied for 4.7 with Kevin's Ack from v5 Thanks Heiko
Re: [PATCH v6 6/6] rockchip: power-domain: Modify power domain driver for rk3399
Am Donnerstag, 10. März 2016, 05:24:38 schrieb Elaine Zhang: > This driver is modified to support RK3399 SoC. > > Signed-off-by: Elaine Zhang applied for 4.7 with small indentation fixes in the domain list Thanks Heiko
[PATCH] rtc: at91sam9: remove duplicate assignment of variable mr
From: Colin Ian King
mr is written twice with the same value, remove one of the
redundant assignments to mr.
Signed-off-by: Colin Ian King
---
drivers/rtc/rtc-at91sam9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index 7206e2f..99732e6 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -268,7 +268,7 @@ static int at91_rtc_alarm_irq_enable(struct device *dev,
unsigned int enabled)
static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
{
struct sam9_rtc *rtc = dev_get_drvdata(dev);
- u32 mr = mr = rtt_readl(rtc, MR);
+ u32 mr = rtt_readl(rtc, MR);
seq_printf(seq, "update_IRQ\t: %s\n",
(mr & AT91_RTT_RTTINCIEN) ? "yes" : "no");
--
2.7.4
Re: [PART1 RFC v3 08/12] KVM: x86: Add trace events for AVIC
Hi Paolo,
On 3/18/16 17:24, Paolo Bonzini wrote:
+ TP_printk("vcpu=%#x, icrh:icrl=%#010x:%08x, id=%u, index=%u\n",
vcpus are usually printed with %u. Apart from this, the patch looks
good. You can squash it in "svm: Add VMEXIT handlers for AVIC".
Paolo
Sure, thanks for the feedback.
Suravee
Re: [PATCH v2 1/3] phy: rockchip-dp: should be a child device of the GRF
Hi Heiko,
On 03/25/2016 05:29 AM, Heiko Stuebner wrote:
The displayport-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate platform-
device but instead a sub-device of the GRF - using the simply-mfd mechanism.
The driver entered the kernel in the current merge-window, so we can still
adapt the binding without needing a fallback, as the binding hasn't been
released with a full kernel yet.
While the edp phy is fully part of the GRF, it doesn't have any separate
register set there, so doesn't get any register-area assigned.
Signed-off-by: Heiko Stuebner
Thanks for your improved.
Reviewed-by: Yakir Yang
---
While one of my intermediate versions did include that conversion
already, it looks like it was lost when the dp-phy got split out into
its own series and I missed that dropped change.
As mentioned in the patch description above, this is meant as a fixup for
kernel 4.6.
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 18 +++---
drivers/phy/phy-rockchip-dp.c | 7 +--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
index 50c4f9b..e3b4809 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -8,15 +8,19 @@ Required properties:
of memory mapped region.
- clock-names: from common clock binding:
Required elements: "24m"
-- rockchip,grf: phandle to the syscon managing the "general register files"
- #phy-cells : from the generic PHY bindings, must be 0;
Example:
-edp_phy: edp-phy {
- compatible = "rockchip,rk3288-dp-phy";
- rockchip,grf = <&grf>;
- clocks = <&cru SCLK_EDP_24M>;
- clock-names = "24m";
- #phy-cells = <0>;
+grf: syscon@ff77 {
+ compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+ edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+ };
};
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index 77e2d02..793ecb6 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -86,6 +86,9 @@ static int rockchip_dp_phy_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
+ if (!dev->parent || !dev->parent->of_node)
+ return -ENODEV;
+
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (IS_ERR(dp))
return -ENOMEM;
@@ -104,9 +107,9 @@ static int rockchip_dp_phy_probe(struct platform_device
*pdev)
return ret;
}
- dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+ dp->grf = syscon_node_to_regmap(dev->parent->of_node);
if (IS_ERR(dp->grf)) {
- dev_err(dev, "rk3288-dp needs rockchip,grf property\n");
+ dev_err(dev, "rk3288-dp needs the General Register Files
syscon\n");
return PTR_ERR(dp->grf);
}
[PATCH v2] hp206c: Initial support for reading sensor values
Hello,
Changes since the first version:
* Use data->client instead of to_i2c_client(indio_dev->dev.parent)
* Adjust i2c_check_functionality bits requested.
I also fixed gitconfig so it won't create attachments or suppress cc.
Signed-off-by: Crestez Dan Leonard
---
drivers/iio/pressure/Kconfig | 10 +
drivers/iio/pressure/Makefile | 1 +
drivers/iio/pressure/hp206c.c | 416 ++
3 files changed, 427 insertions(+)
create mode 100644 drivers/iio/pressure/hp206c.c
diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index 31c0e1f..8de0192 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -148,4 +148,14 @@ config T5403
To compile this driver as a module, choose M here: the module
will be called t5403.
+config HP206C
+ tristate "HOPERF HP206C precision barometer and altimeter sensor"
+ depends on I2C
+ help
+ Say yes here to build support for the HOPREF HP206C precision
+ barometer and altimeter sensor.
+
+ This driver can also be built as a module. If so, the module will
+ be called hp206c.
+
endmenu
diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
index d336af1..6e60863 100644
--- a/drivers/iio/pressure/Makefile
+++ b/drivers/iio/pressure/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_IIO_ST_PRESS) += st_pressure.o
st_pressure-y := st_pressure_core.o
st_pressure-$(CONFIG_IIO_BUFFER) += st_pressure_buffer.o
obj-$(CONFIG_T5403) += t5403.o
+obj-$(CONFIG_HP206C) += hp206c.o
obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
diff --git a/drivers/iio/pressure/hp206c.c b/drivers/iio/pressure/hp206c.c
new file mode 100644
index 000..9c2c49d
--- /dev/null
+++ b/drivers/iio/pressure/hp206c.c
@@ -0,0 +1,416 @@
+/*
+ * hp206c.c - HOPERF HP206C precision barometer and altimeter sensor
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * (7-bit I2C slave address 0x76)
+ *
+ * Datasheet:
+ * http://www.hoperf.com/upload/sensor/HP206C_DataSheet_EN_V2.0.pdf
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* I2C commands: */
+#define HP206C_CMD_SOFT_RST0x06
+
+#define HP206C_CMD_ADC_CVT 0x40
+
+#define HP206C_CMD_ADC_CVT_OSR_40960x00
+#define HP206C_CMD_ADC_CVT_OSR_20480x04
+#define HP206C_CMD_ADC_CVT_OSR_10240x08
+#define HP206C_CMD_ADC_CVT_OSR_512 0x0c
+#define HP206C_CMD_ADC_CVT_OSR_256 0x10
+#define HP206C_CMD_ADC_CVT_OSR_128 0x14
+
+#define HP206C_CMD_ADC_CVT_CHNL_PT 0x00
+#define HP206C_CMD_ADC_CVT_CHNL_T 0x02
+
+#define HP206C_CMD_READ_P 0x30
+#define HP206C_CMD_READ_T 0x32
+
+#define HP206C_CMD_READ_REG0x80
+#define HP206C_CMD_WRITE_REG 0xc0
+
+#define HP206C_REG_INT_EN 0x0b
+#define HP206C_REG_INT_CFG 0x0c
+
+#define HP206C_REG_INT_SRC 0x0d
+#define HP206C_FLAG_DEV_RDY0x40
+
+#define HP206C_REG_PARA0x0f
+#define HP206C_FLAG_CMPS_EN0x80
+
+/* Maximum spin for DEV_RDY */
+#define HP206C_MAX_DEV_RDY_WAIT_COUNT 20
+#define HP206C_DEV_RDY_WAIT_US2
+
+struct hp206c_data {
+ struct mutex mutex;
+ struct i2c_client *client;
+ u8 temp_osr_index;
+ u8 pres_osr_index;
+};
+
+struct hp206c_osr_setting {
+ u8 osr_mask;
+ unsigned int temp_conv_time_us;
+ unsigned int pres_conv_time_us;
+};
+
+/* Data from Table 5 in datasheet. */
+static const struct hp206c_osr_setting hp206c_osr_settings[] = {
+ { HP206C_CMD_ADC_CVT_OSR_4096, 65600, 131100},
+ { HP206C_CMD_ADC_CVT_OSR_2048, 32800, 65600},
+ { HP206C_CMD_ADC_CVT_OSR_1024, 16400, 32800},
+ { HP206C_CMD_ADC_CVT_OSR_512, 8200, 16400},
+ { HP206C_CMD_ADC_CVT_OSR_256, 4100, 8200},
+ { HP206C_CMD_ADC_CVT_OSR_128, 2100, 4100},
+};
+static const int hp206c_osr_rates[] = { 4096, 2048, 1024, 512, 256, 128 };
+static const char hp206c_osr_rates_str[] = "4096 2048 1024 512 256 128";
+
+static inline int hp206c_read_reg(struct i2c_client *client, u8 reg)
+{
+ return i2c_smbus_read_byte_data(client, HP206C_CMD_READ_REG | reg);
+}
+
+static inline int hp206c_write_reg(struct i2c_client *client, u8 reg, u8 val)
+{
+ return i2c_smbus_write_byte_data(client,
+ HP206C_CMD_WRITE_REG | reg, val);
+}
+
+static int hp206c_read_20bit(struct i2c_client *client, u8 cmd)
+{
+ int ret;
+ uint8_t values[3];
+
+ ret = i2c_smbus_read_i2c_block_data(client, cmd, 3, values);
+ if (ret < 0)
+ return ret;
+ if (ret != 3)
+ return -EIO;
+ return ((values[0] & 0xF) << 16) | (values[1] << 8) | (values[2]);
+}
+
+/* Spin for max 160ms until DEV_RDY is
[PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats
From: Colin Ian King isr_stats is written twice with the same value, remove one of the redundant assignments to isr_stats. Signed-off-by: Colin Ian King --- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c index 4be3c35..253e4f0 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void *dev_id) struct msix_entry *entry = dev_id; struct iwl_trans_pcie *trans_pcie = iwl_pcie_get_trans_pcie(entry); struct iwl_trans *trans = trans_pcie->trans; - struct isr_statistics *isr_stats = isr_stats = &trans_pcie->isr_stats; + struct isr_statistics *isr_stats = &trans_pcie->isr_stats; u32 inta_fh, inta_hw; lock_map_acquire(&trans->sync_cmd_lockdep_map); -- 2.7.4
[PATCH 5/5 v5] arc: axs10x - add support of ARC PGU
Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.
That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Vineet Gupta
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
---
No changes v4 -> v5.
Changes v3 -> v4:
* Removed "0x" from node names (as suggested by Rob)
No changes v2 -> v3.
Changes v1 -> v2:
* Added missing "pxlclk" clock in axs10x_mb.dtsi
arch/arc/boot/dts/axs10x_mb.dtsi | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..8fee596 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -34,6 +34,12 @@
clock-frequency = <5000>;
#clock-cells = <0>;
};
+
+ pguclk: pguclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <7444>;
+ };
};
ethernet@0x18000 {
@@ -147,6 +153,37 @@
clocks = <&i2cclk>;
interrupts = <16>;
+ adv7511:adv7511@39{
+ compatible="adi,adv7511";
+ reg = <0x39>;
+ interrupts = <23>;
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,clock-delay = <0x03>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* RGB/YUV input */
+ port@0 {
+ reg = <0>;
+ adv7511_input:endpoint {
+ remote-endpoint = <&pgu_output>;
+ };
+ };
+
+ /* HDMI output */
+ port@1 {
+ reg = <1>;
+ adv7511_output: endpoint {
+ remote-endpoint =
<&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
eeprom@0x54{
compatible = "24c01";
reg = <0x54>;
@@ -160,6 +197,16 @@
};
};
+ hdmi0: connector {
+ compatible = "hdmi-connector";
+ type = "a";
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&adv7511_output>;
+ };
+ };
+ };
+
gpio0:gpio@13000 {
compatible = "snps,dw-apb-gpio";
reg = <0x13000 0x1000>;
@@ -221,5 +268,19 @@
reg = <2>;
};
};
+
+ pgu@17000 {
+ compatible = "snps,arcpgu";
+ reg = <0x17000 0x400>;
+ encoder-slave = <&adv7511>;
+ clocks = <&pguclk>;
+ clock-names = "pxlclk";
+
+ port {
+ pgu_output: endpoint {
+ remote-endpoint = <&adv7511_input>;
+ };
+ };
+ };
};
};
--
2.5.0
[PATCH 1/5 v5] drm: Add support of ARC PGU display controller
From: Carlos Palminha
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Carlos Palminha
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-snps-...@lists.infradead.org
---
Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61
No changes v4 -> v5.
Changes v3 -> v4:
* The driver author is now set properly (thanks Carlos for all your efforts)
* Implemented correct hsync and vsync setup (thanks Jose)
* Dummy call-backs were removed (as suggested by Daniel)
* Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
* With above in mind we were able to adopt recently introduced
drm_connector_register_all()/drm_connector_unregister_all()
Changes v2 -> v3:
* Improved failure path if arcpgu_connector wasn't allocated (thanks Jose).
* Fixed driver building as module (reported by 0-DAY kernel test infrastruct.)
* Implemented uncached mapping of user-space FB pages.
No changes v1 -> v2.
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arc/Kconfig | 10 ++
drivers/gpu/drm/arc/Makefile | 2 +
drivers/gpu/drm/arc/arcpgu.h | 50 +++
drivers/gpu/drm/arc/arcpgu_crtc.c | 257 ++
drivers/gpu/drm/arc/arcpgu_drv.c | 282 ++
drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++
drivers/gpu/drm/arc/arcpgu_regs.h | 40 ++
9 files changed, 845 insertions(+)
create mode 100644 drivers/gpu/drm/arc/Kconfig
create mode 100644 drivers/gpu/drm/arc/Makefile
create mode 100644 drivers/gpu/drm/arc/arcpgu.h
create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2a74d0..9e4f2f1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -281,3 +281,5 @@ source "drivers/gpu/drm/imx/Kconfig"
source "drivers/gpu/drm/vc4/Kconfig"
source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/arc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..c338d04 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,3 +78,4 @@ obj-y += panel/
obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_ARCPGU)+= arc/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
new file mode 100644
index 000..f9a13b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -0,0 +1,10 @@
+config DRM_ARCPGU
+ tristate "ARC PGU"
+ depends on DRM && OF
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
new file mode 100644
index 000..d48fda7
--- /dev/null
+++ b/drivers/gpu/drm/arc/Makefile
@@ -0,0 +1,2 @@
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
new file mode 100644
index 000..86574b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -0,0 +1,50 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * 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.
+ *
+ */
+
+#ifndef _ARCPGU_H_
+#define _ARCPGU_H_
+
+struct arcpgu_drm_private {
+ void __iomem*regs;
+ struct clk *clk;
+ struct drm_fbdev_cma*fbdev;
+ struct drm_framebuffer *fb;
+ struct list_headevent_list;
+ struct drm_crtc crtc;
+ struct drm_plane*plane;
+};
+
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+ iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+
[PATCH 2/5 v5] drm: Add DT bindings documentation for ARC PGU display controller
This add DT bindings documentation for ARC PGU display controller.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Acked-by: Rob Herring
---
Changes v4 -> v5: (addressing Rob's comment)
* Added Rob's acked-by
* Remove "encoder-slave" from the example as well.
Now only "pgu" node is mentioned in the example.
Changes v3 -> v4: (addressing Rob's comments)
* Removed "encoder-slave" from required properties
* Removed "0x" from node names
Changes v2 -> v3:
* Reverted back to initial larger version of example
with minor fixes (thanks Rob for spotting those).
Changes v1 -> v2:
* Removed everything except PGU node itself.
.../devicetree/bindings/display/snps,arcpgu.txt| 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
new file mode 100644
index 000..c5c7dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
@@ -0,0 +1,35 @@
+ARC PGU
+
+This is a display controller found on several development boards produced
+by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
+framebuffer and sends it to a single digital encoder (usually HDMI).
+
+Required properties:
+ - compatible: "snps,arcpgu"
+ - reg: Physical base address and length of the controller's registers.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For ARC PGU it should contain:
+ - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+ - port: The PGU connection to an encoder chip.
+
+Example:
+
+/ {
+ ...
+
+ pgu@ {
+ compatible = "snps,arcpgu";
+ reg = <0x 0x400>;
+ clocks = <&clock_node>;
+ clock-names = "pxlclk";
+
+ port {
+ pgu_output: endpoint {
+ remote-endpoint = <&hdmi_enc_input>;
+ };
+ };
+ };
+};
--
2.5.0
[PATCH 0/5 v5] drm: Add support of ARC PGU display controller
This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101/103 in particular). Note following series that introduces drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite now: https://lkml.org/lkml/2016/3/23/61 Changes v4 -> v5: * Removed encode node from DT bindings example (as suggested by Rob) Changes v3 -> v4: * Main driver author is now set properly (thanks Carlos for all your efforts) * Implemented correct hsync and vsync setup (thanks Jose) * Dummy call-backs were removed (as suggested by Daniel) * Obsolete load()/unload() call-backs were removed (as suggested by Daniel) * With above in mind we were able to adopt recently introduced drm_connector_register_all()/drm_connector_unregister_all() * Implemented setup of properties (uncached) for FB user-pages * Minor clean-up in DT binding docs and axs10x_mb.dtsi Changes v2 -> v3: * Improved failure path if arcpgu_connector wasn't allocated. * Fixed driver building as module. * Implemented uncached mapping of user-space FB pages. * Again updated DT bindings docs. Changes v1 -> v2: * Clean-up of DT bindings documentation. * Added missing "pxlclk" clock in axs10x_mb.dtsi. Cc: David Airlie Cc: devicet...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: Ian Campbell Cc: Kumar Gala Cc: linux-snps-...@lists.infradead.org Cc: Mark Rutland Cc: Pawel Moll Cc: Rob Herring Cc: Vineet Gupta Cc: Jose Abreu Cc: Carlos Palminha Alexey Brodkin (4): drm: Add DT bindings documentation for ARC PGU display controller MAINTAINERS: Add maintainer for ARC PGU display controller arc: Add our own implementation of fb_pgprotect() arc: axs10x - add support of ARC PGU Carlos Palminha (1): drm: Add support of ARC PGU display controller .../devicetree/bindings/display/snps,arcpgu.txt| 35 +++ MAINTAINERS| 6 + arch/arc/boot/dts/axs10x_mb.dtsi | 61 + arch/arc/include/asm/fb.h | 19 ++ drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arc/Kconfig| 10 + drivers/gpu/drm/arc/Makefile | 2 + drivers/gpu/drm/arc/arcpgu.h | 50 drivers/gpu/drm/arc/arcpgu_crtc.c | 257 +++ drivers/gpu/drm/arc/arcpgu_drv.c | 282 + drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++ drivers/gpu/drm/arc/arcpgu_regs.h | 40 +++ 13 files changed, 966 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt create mode 100644 arch/arc/include/asm/fb.h create mode 100644 drivers/gpu/drm/arc/Kconfig create mode 100644 drivers/gpu/drm/arc/Makefile create mode 100644 drivers/gpu/drm/arc/arcpgu.h create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h -- 2.5.0
[PATCH 4/5 v5] arc: Add our own implementation of fb_pgprotect()
During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.
In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
* Huge amount of data if passing through data cache will
thrash cache a lot making cache almost useless for other
less traffic hungry processes.
* Data written by user in FB will be immediately available for
hardware (such as PGU etc) without requirements to flush data
cache regularly.
Signed-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
---
No changes v4 -> v5.
Changes v3 -> v4:
* This change was introduced only in v4.
arch/arc/include/asm/fb.h | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 arch/arc/include/asm/fb.h
diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
new file mode 100644
index 000..bd3f68c
--- /dev/null
+++ b/arch/arc/include/asm/fb.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_FB_H_
+#define _ASM_FB_H_
+
+#include
+#include
+#include
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+ unsigned long off)
+{
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+ return 0;
+}
+
+#endif /* _ASM_FB_H_ */
--
2.5.0
[PATCH 3/5 v5] MAINTAINERS: Add maintainer for ARC PGU display controller
This updates MAINTEINERS file with information about maintainer of ARC PGU display controller driver. Signed-off-by: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org --- No changes v4 -> v5. No changes v3 -> v4. No changes v2 -> v3. No changes v1 -> v2. MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ea1d1de..0dcba67 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -827,6 +827,12 @@ S: Maintained F: drivers/net/arcnet/ F: include/uapi/linux/if_arcnet.h +ARC PGU DRM DRIVER +M: Alexey Brodkin +S: Supported +F: drivers/gpu/drm/arc/ +F: Documentation/devicetree/bindings/display/snps,arcpgu.txt + ARM HDLCD DRM DRIVER M: Liviu Dudau S: Supported -- 2.5.0
Re: Warnings for invalid VDD (sdhci-s3c)
Hi Krzysztof,
On 28 March 2016 at 11:03, Krzysztof Kozlowski wrote:
> On 27.03.2016 16:41, Anand Moon wrote:
>>
>> On My Odroid U3 with debug flags enable I am observing bellow deadlock.
>
> There is a sleep in atomic context and possible deadlock, but:
> 1. Are you sure it does not happen without the patch?
I have tested this with this patch applied.
> 2. Are you sure it is not the same as already known issue on sdhci-s3c?
> For example reported here:
> http://www.spinics.net/lists/linux-samsung-soc/msg42398.html
Ok this is know issue.
>
> What is reproducibility rate?
It's reproducible intermediately.
If I am doing some thing wrong please ignore this.
Attach is the config options.
Best Regards.
-Anand Moon
>
> Best regards,
> Krzysztof
>
>> -
>> [ 202.519524] BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:617
>> [ 202.522364] in_atomic(): 1, irqs_disabled(): 128, pid: 100, name: mmcqd/0
>> [ 202.529129] 1 lock held by mmcqd/0/100:
>> [ 202.529150] #0: (&(&host->lock)->rlock#2){-.-...}, at:
>> [] sdhci_do_set_ios+0x1c/0x484
>> [ 202.529271] irq event stamp: 703530
>> [ 202.529291] hardirqs last enabled at (703529): []
>> _raw_spin_unlock_irqrestore+0x6c/0x74
>> [ 202.529343] hardirqs last disabled at (703530): []
>> _raw_spin_lock_irqsave+0x1c/0x84
>> [ 202.529384] softirqs last enabled at (703456): []
>> __do_softirq+0x244/0x2c0
>> [ 202.529438] softirqs last disabled at (703445): []
>> irq_exit+0xec/0x128
>> [ 202.529472] Preemption disabled at:[< (null)>] (null)
>> [ 202.534415]
>> [ 202.534449] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
>> [ 202.534473] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 202.534544] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [ 202.534594] [] (show_stack) from []
>> (dump_stack+0x98/0xc4)
>> [ 202.534639] [] (dump_stack) from []
>> (mutex_lock_nested+0x2c/0x4dc)
>> [ 202.534685] [] (mutex_lock_nested) from []
>> (clk_prepare_lock+0x50/0xf8)
>> [ 202.534726] [] (clk_prepare_lock) from []
>> (clk_round_rate+0x1c/0x58)
>> [ 202.534773] [] (clk_round_rate) from []
>> (sdhci_s3c_set_clock+0x18c/0x1b0)
>> [ 202.534819] [] (sdhci_s3c_set_clock) from []
>> (sdhci_cmu_set_clock+0x24/0x17c)
>> [ 202.534860] [] (sdhci_cmu_set_clock) from []
>> (sdhci_do_set_ios+0x78/0x484)
>> [ 202.534904] [] (sdhci_do_set_ios) from []
>> (sdhci_runtime_resume_host+0x60/0x114)
>> [ 202.534957] [] (sdhci_runtime_resume_host) from
>> [] (__rpm_callback+0x2c/0x60)
>> [ 202.535000] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [ 202.535041] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [ 202.535081] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [ 202.535125] [] (__pm_runtime_resume) from []
>> (__mmc_claim_host+0x1b4/0x1f8)
>> [ 202.535176] [] (__mmc_claim_host) from []
>> (mmc_sd_runtime_resume+0x20/0xac)
>> [ 202.535220] [] (mmc_sd_runtime_resume) from []
>> (__rpm_callback+0x2c/0x60)
>> [ 202.535259] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [ 202.535299] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [ 202.535340] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [ 202.535379] [] (__pm_runtime_resume) from []
>> (mmc_get_card+0x14/0x24)
>> [ 202.535420] [] (mmc_get_card) from []
>> (mmc_blk_issue_rq+0x258/0x4f0)
>> [ 202.535461] [] (mmc_blk_issue_rq) from []
>> (mmc_queue_thread+0xd0/0x1d8)
>> [ 202.535513] [] (mmc_queue_thread) from []
>> (kthread+0xf4/0x10c)
>> [ 202.535561] [] (kthread) from []
>> (ret_from_fork+0x14/0x24)
>> [ 202.535624]
>> [ 202.535893] ==
>> [ 202.542059] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
>> [ 202.548742] 4.6.0-rc1-u3s #38 Not tainted
>> [ 202.552732] --
>> [ 202.558902] mmcqd/0/100 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
>> [ 202.565317] (prepare_lock){+.+...}, at: []
>> clk_prepare_lock+0x50/0xf8
>> [ 202.572695]
>> [ 202.572695] and this task is already holding:
>> [ 202.578510] (&(&host->lock)->rlock#2){-.-...}, at: []
>> sdhci_do_set_ios+0x1c/0x484
>> [ 202.586930] which would create a new lock dependency:
>> [ 202.591964] (&(&host->lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
>> [ 202.598650]
>> [ 202.598650] but this new dependency connects a HARDIRQ-irq-safe lock:
>> [ 202.606546] (&(&host->lock)->rlock#2){-.-...}
>> [ 202.606546] ... which became HARDIRQ-irq-safe at:
>> [ 202.614359] [] _raw_spin_lock+0x3c/0x74
>> [ 202.619219] [] sdhci_irq+0x1c/0x814
>> [ 202.623732] [] handle_irq_event_percpu+0x9c/0x150
>> [ 202.629461] [] handle_irq_event+0x38/0x5c
>> [ 202.634495] [] handle_fasteoi_irq+0xd0/0x1a8
>> [ 202.639790] [] generic_handle_irq+0x24/0x34
>> [ 202.644998] [] __handle_doma
Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats
On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote: > From: Colin Ian King > > isr_stats is written twice with the same value, remove one of the > redundant assignments to isr_stats. > > Signed-off-by: Colin Ian King > --- Applied - thanks. > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > index 4be3c35..253e4f0 100644 > --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, > void *dev_id) > struct msix_entry *entry = dev_id; > struct iwl_trans_pcie *trans_pcie = > iwl_pcie_get_trans_pcie(entry); > struct iwl_trans *trans = trans_pcie->trans; > - struct isr_statistics *isr_stats = isr_stats = &trans_pcie > ->isr_stats; > + struct isr_statistics *isr_stats = &trans_pcie->isr_stats; > u32 inta_fh, inta_hw; > > lock_map_acquire(&trans->sync_cmd_lockdep_map);
Re: ARC dw-mshc binding compat string
On 03/28/2016 07:55 PM, Alexey Brodkin wrote:
> Hi Jaehoon,
>
> On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
>> Hi,
>
> [snip]
>
>
> That said, I would rather prefer to see "snps,dw-mshc" prefix on
> description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc"
> seems
> to be redundant.
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>
> So for socfpga platform compat string should be something like
> "snps,dw-mshc-socfpga" then?
i think yes..since there is no SoC specific feature, isn't?
>
>>>
>
>>
>>>
According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
"altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
"img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
one needs it as well, but most likely yes.
I wonder if that bit is needed on some particular version of the DWMMC
core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
binding ? Or should we use DT property to discern the need for this
bit ?
>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
Right, this very much matches how I see it as well. Thanks for confirming.
Alexey, can you tell us if the requirement for setting
SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
disappeared with some revision OR if this is some configuration
option of the core during synthesis ?
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using
>> continuously.
>> But it's difficult to use the generic feature..because it's considered the
>> below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit
>> is set to 0,
>> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit
>> is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>
> So card type is also important here and for certain card type we don't need to
> set SDMMC_CMD_USE_HOLD_REG, right?
If you means card-type is card's speed mode, right..it's important.
In IP Databook, not mentioned about HS200 or HS400, but i thinks it doesn't
need to set USE_HOLD_REG.
Because higher speed mode than 50MHz should be required the lowest input hold
time. (~0.8ns)
>
>> We need to check phase shift scheme..but as i knew, each SoC have been
>> implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
>
> Given my assumption above we need to check 2 things:
> * Card type
> * SoC-specific implementation detail (phase shift scheme)
In Exynos's case, there is CLKSEL register in DWMMC IP register.(as Vendor
specific register.)
On other hands, rockchip is handling the phase sfiht with "clk_set_phase()"(as
CMU.)
I can't know everything how they're implementing for shifting phase..
>
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
>
> Ah actually 3 things
> + IMPLEMENT_HOLD_REG
Almost all have IMPLEMENT_HOLD_REG...?
If i will implement... in dw-mmc.c
switch (ios->timing) {
case SDR50/DDR50/.../
if (check cclk_in_drv > 0 for each SoC) {
SDMMC_CMD_USE_HOLD_REG is set to 1
break;
}
case SDR12/SD25
SDMMC_CMD_USE_HOLD_REG is set to 1
default:
SDMMC_CMD_USE_HOLD_REG is set to 0.
}
>
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i
>> recommend to use "snps,dw-mshc" for ARC compat
>> string.
>> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the
>> basic dw-mmc controller functionality.
>
> Hm, interesting looks like you already made some changes here:
> http://gi
Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
Hi Emilio, On 9 March 2016 at 15:28, Emilio López wrote: > These tests are based on the libsync test suite from Android. > This commit lays the ground for future tests, as well as includes > tests for a variety of basic allocation commands. > > Signed-off-by: Gustavo Padovan > Signed-off-by: Emilio López > --- > > tools/testing/selftests/sync/sync.h | 119 ++ Admittedly I know nothing about the kernel selftests although copying the UAPI header, seems to defeat the purpose of this exercise. Shouldn't one reuse the existing header ? It would even cause issues as the interface gets updated (iirc Gustavo changed the ioctl numbers and/or header name with latter series). Regards, Emil
Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]
Hi David,
On Wed, 2016-03-09 at 11:19 +, David Howells wrote:
> Provide a config option (IMA_PERMIT_ADD_TO_IMA_KEYRINGS) that, when
> enabled, allows keys to be added to the IMA keyrings by userspace - with
> the restriction that each must be signed by a key in the system trusted
> keyrings.
>
> EPERM will be returned if this option is disabled, ENOKEY will be returned if
> no authoritative key can be found and EKEYREJECTED will be returned if the
> signature doesn't match. Other errors such as ENOPKG may also be returned.
>
> If this new option is enabled, the builtin system keyring is searched, as is
> the secondary system keyring if that is also enabled. Intermediate keys
> between the builtin system keyring and the key being added can be added to
> the secondary keyring (which replaces .ima_mok) to form a trust chain -
> provided they are also validly signed by a key in one of the trusted keyrings.
>
> The .ima_mok keyring is removed.
This patch adds new Kconfig options, when it should be limited to
removing the .ima_mok keyring. Lets change the title to "IMA: use the
secondary_trusted_keys instead of .ima_mok" and limit the new Kconfig
option to using the secondary_trusted_keys.
> Signed-off-by: David Howells
> ---
>
> include/keys/system_keyring.h|9 --
> security/integrity/digsig.c | 33
> security/integrity/ima/Kconfig | 62
> +++---
> security/integrity/ima/ima_mok.c | 15 ++---
> 4 files changed, 60 insertions(+), 59 deletions(-)
>
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 614424029de7..87eeea4b816c 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -34,22 +34,13 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
> #endif
>
> #ifdef CONFIG_IMA_MOK_KEYRING
> -extern struct key *ima_mok_keyring;
> extern struct key *ima_blacklist_keyring;
>
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return ima_mok_keyring;
> -}
> static inline struct key *get_ima_blacklist_keyring(void)
> {
> return ima_blacklist_keyring;
> }
> #else
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return NULL;
> -}
> static inline struct key *get_ima_blacklist_keyring(void)
> {
> return NULL;
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 98ee4c752cf5..ef2f911d5c76 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -42,32 +42,12 @@ static bool init_keyring __initdata = true;
> static bool init_keyring __initdata;
> #endif
>
> -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
> -/*
> - * Restrict the addition of keys into the IMA keyring.
> - *
> - * Any key that needs to go in .ima keyring must be signed by CA in
> - * either .system or .ima_mok keyrings.
> - */
> -static int restrict_link_by_ima_mok(struct key *keyring,
> - const struct key_type *type,
> - const union key_payload *payload)
> -{
> - int ret;
> -
> - ret = restrict_link_by_builtin_trusted(keyring, type, payload);
> - if (ret != -ENOKEY)
> - return ret;
> -
> - return restrict_link_by_signature(get_ima_mok_keyring(),
> - type, payload);
> -}
> +#if defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN)
> +#define restrict_link_to_ima restrict_link_by_builtin_trusted
> +#elif defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY)
> +#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
> #else
> -/*
> - * If there's no system trusted keyring, then keys cannot be loaded into
> - * .ima_mok and added keys cannot be marked trusted.
> - */
> -#define restrict_link_by_ima_mok restrict_link_reject
> +#define restrict_link_to_ima restrict_link_reject
> #endif
>
> int integrity_digsig_verify(const unsigned int id, const char *sig, int
> siglen,
> @@ -114,7 +94,8 @@ int __init integrity_init_keyring(const unsigned int id)
>KEY_USR_VIEW | KEY_USR_READ |
>KEY_USR_WRITE | KEY_USR_SEARCH),
> KEY_ALLOC_NOT_IN_QUOTA,
> - restrict_link_by_ima_mok, NULL);
> + restrict_link_to_ima,
> + NULL);
> if (IS_ERR(keyring[id])) {
> err = PTR_ERR(keyring[id]);
> pr_info("Can't allocate %s keyring (%d)\n",
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index e54a8a8dae94..90a65fba6f39 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -156,22 +156,60 @@ config IMA_TRUSTED_KEYRING
> This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
>
> config IMA_MOK_KEYRING
As we're left with only the IMA bl
Re: [PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.
Hi all,
On 24 March 2016 at 11:28, Dan Carpenter wrote:
> On Thu, Mar 24, 2016 at 11:41:46AM +0100, Enric Balletbo i Serra wrote:
>> + /* Map slave addresses of ANX7814 */
>> + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
>> + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
>> + anx78xx_i2c_addresses[i] >> 1);
>> + if (!anx78xx->i2c_dummy[i]) {
>> + DRM_ERROR("Failed to reserve i2c bus %02x.\n",
>> + anx78xx_i2c_addresses[i]);
>
> Missing error code here.
>
>> + goto err_i2c;
>> + }
>
> I'm, of course, not a fan of the naming. The name should be based on
> what the goto location does... In this case it turns it off. Which is
> slightly weird because we have not turned it on yet... I always say
> that you should have multiple error labels and you only undo things
> which have been done.
>
> Having a common exit path for the other functions where it was "goto out"
> makes sense. But again in those cases I would prefer a meaningful label
> name like "goto unlock;". In the kernel "goto out;" is meaningless, it
> could do anything or everything or nothing. A lot of people like it
> of course, but out: label code tends to be buggier than using a
> meaningful name.
>
Dan, I'm so glad to see another like minded person on the topic. It
seems that we're a minority though :-(
Enric, if you want to increase the chances of this getting reviewed I
would humbly suggest adding a per-patch changelog (must), explicitly
Cc (in the commit message) the people who commented on your patch
(highly recommended), and perhaps cutting down the 20+ people from the
To/Cc list (nitpicking).
Another option would be to assist/review similar (drm bridge) patches
for other contributors, who should return with the same :-)
Just some suggestions (my 2c as they say), seeing that this has been
around for a while.
Regards,
Emil
Re: [RFC PATCH v1 0/4] Add Rockchip RGA support
On 22 March 2016 at 00:42, Heiko Stuebner wrote: > Hi Yakir, > > Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang: >> On 03/21/2016 07:29 PM, Heiko Stübner wrote: >> > Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang: >> >> This patch set would add the RGA direct rendering based 2d graphics >> >> acceleration module. >> > >> > very cool to see that. >> >> ;) >> >> >> This patch set is based on git repository below: >> >> git://people.freedesktop.org/~airlied/linux drm-next >> >> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7 >> >> >> >> And the RGA driver is based on Exynos G2D driver, it only manages the >> >> command lists received from user, so user should make the command list >> >> to data and registers needed by operation to use. >> >> >> >> I have prepared an userspace demo application for testing: >> >>https://github.com/yakir-Yang/libdrm-rockchip >> >> >> >> That is a rockchip libdrm library, and I have write a simple test case >> >> "rockchip_rga_test" that would test the below RGA features: >> >> - solid >> >> - copy >> >> - rotation >> >> - flip >> >> - window clip >> >> - dithering >> > >> > Did you submit your libdrm changes as well? >> > >> > Userspace-interfaces need to be stable so the other side must also get >> > accepted - even before the kernel change if I remember correctly. >> >> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm. >> But I don't find the way to submit patches to libdrm, would you like >> share some helps here ;) > > Looking at the libdrm sources on cgit.freedesktop.org, I did not find any > specific manual on submitting patches. > > But looking at the dri-list archive, dri-de...@lists.freedesktop.org is the > right list and looking at the libdrm history it looks like Emil Velikov > seems to be doing maintenance-stuff in libdrm. > And as a 3rd recipient, please also include the linux-rockchip list. > > @Emil, please shout if I read that wrong :-) > You got it spot on Heiko. There are a few notes though... As one reuses the existing hardware/IP block, it would be better to avoid copy/pasting code around. Namely: - (if possible) factor out the exynos g2d kernel functionality to a separate kernel module and wire up the rockhip (via dt ?) to use it - factor out the g2d specifics out of exynos_drm.h (into exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the new header - if neither of these are possible, then please ensure that the new header uses correct types (see the docs [1]), use MIT/X11 license (if possible) and link where upstream userspace is happy with the interface (ideally more than a simple test app like libdrm) These might sound like an overkill, although getting UAPI right and maintaining it forever forces us to do so. Regards, Emil [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
Re: [PATCH 1/1] perf tools: Fix build break on powerpc
Em Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu escreveu:
> From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Sat, 26 Mar 2016 17:31:39 -0400
> Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> kernel sources")' seems to have accidentially removed the inclusion of
> "util/header.h" from "arch/powerpc/util/header.c".
My bad, will push this via perf/urgent, after fixing what Jiri reported.
> "util/header.h" provides the prototype for get_cpuid() and is needed to
> build perf on Powerpc.
>
> arch/powerpc/util/header.c:17:1: error: no previous prototype for
> ‘get_cpuid’ [-Werror=missing-prototypes]
>
> Reported-by: Michael Ellerman
> Signed-off-by: Sukadev Bhattiprolu
> ---
> tools/perf/arch/powerpc/util/header.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/arch/powerpc/util/header.c
> b/tools/perf/arch/powerpc/util/header.c
> index 6138bde..5111e34 100644
> --- a/tools/perf/arch/powerpc/util/header.c
> +++ b/tools/perf/arch/powerpc/util/header.c
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include "../../util/header.h"
>
> #define mfspr(rn) ({unsigned long rval; \
>asm volatile("mfspr %0," __stringify(rn) \
> --
> 1.8.3.1
Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc
Em Mon, Mar 28, 2016 at 04:28:45PM +0530, Ravi Bangoria escreveu: > Thanks Arnaldo for putting the effort. > > I've tested this patch on powerpc and it looks fine to me. Please find my > below comments. > > On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote: > >Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu: > >>Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu: > >>>Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu: > 'perf kvm record' is not available on powerpc because 'perf' relies on > the 'cycles' event (a PMU event) to profile the guest. However, for > powerpc, this can't be used from the host because the PMUs are controlled > by the guest rather than the host. > > There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is > hit whenever any of the threads exit the guest context. The guest > instruction pointer dumped along with this tracepoint data in the field > 'pc', can be used as guest instruction pointer. > > This patch changes default event as kvm_hv:kvm_guest_exit for recording > guest data in host on powerpc. As we are using host event to record guest > data, this approach will enable only --guest option of 'perf kvm'. Still > --host --guest together won't work. > >>>It should, i.e. --host --guest should translate to: > >>> > >>>-e cycles:H,kvm_hv:kvm_guest_exit > >>> > >>>I.e. both collect cycles only in the host, and also the tracepoint that > >>>will allow us to get the guest approximation for the unavailable cycles > >>>event, no? > >>> > >>>I'm putting the infrastructure work needed for this the perf/cpumode > >>>branch. More work will be put there soon. > >>So I took a different path and made perf_evsel__parse_sample set a new > >>perf_sample.cpumode field, this way we'll end up having just to set a > >>per-evsel ->post_parse_sample() callback for the event that replaces > >>"cycles" for PPC guests where we'll just set data->ip and data->cpumode, > >>the rest of the code remains unchanged. > >> > >>The changes I made looks useful in itself, as, IIRC more code was > >>removed than added. > >> > >>I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for > >>testing, that has: > >Ok, so the infrastructure got merged already and from there the next > >steps are in running with: > > > > perf kvm --guest record -a -e cycles:H,kvm:kvm_exit > > > >And then, with the patch below applied, try: > > > >perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report > >-i perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit > > > The initial proposal was to change the default event as "kvm_guest_exit" for > kvm recording/reporting > on ppc. If I understand it correctly, your patch creates a handler for > reporting kvm events > based on "munge_ppc_guest_event" and the required tracepoint i.e., we need > to mention the > required tracepoint event name for recording and reporting. What is present in my patch is the creation of infrastructure that is as much generic as possible, to enable doing this event conversion for PPC. Doing it transparently in PPC systems and on other systems when handling a perf.data file generated by 'perf kvm record' on PPC will be done on top of this, thanks for testing, I'll send a complete series soon. - Arnaldo > There might be a little bit of an issue here. For scripts which depend on > generic perf kvm record/report, > we need to change those appropriately to prevent those from failing on > powerpc. Otherwise, (just a > thought) can we create some kind of an alias to map the ppc specific perf > kvm commands with the > generic perf kvm. > For e.g : > perf kvm record -e "kvm_hv:kvm_guest_exit" mapped to perf kvm record > & > perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped to > perf kvm report. > > > Regards, > Ravi
Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem
On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote: > On Sat, 12 Mar 2016, Kirill A. Shutemov wrote: ... > As I've said on several occasions, I am not interested in emulating > the limitations of hugetlbfs inside tmpfs: there might one day be a > case for such a project, but it's transparent hugepages that we want to > have now - blocksize 4kB, but in 2MB extents when possible (on x86_64). > > I accept that supporting small files correctly is not the #1 > requirement for a "huge" tmpfs; and if it were impossible or > unreasonable to ask for, I'd give up on it. But since we (Google) > have been using a successful implementation for a year now, I see > no reason to give up on it at all: it allows for much wider and > easier adoption (and testing) of huge tmpfs - without "but"s. I think, once we get collapse work, huge=within_size would provide reasonable support for fs with mixed-sized files. Yes, we still would have overhead on sparsed or punch-holed files. As for now, I don't see it being show-stopper. The hugepage allocation policy can be overwritten with MADV/FADV_NOHUGEPAGE if an application don't want to see huge pages in a particular case. ... > Hmm, I just went to repeat that test, to see if MemFree goes down and > down on each run, but got a VM_BUG_ON_PAGE(page_ref_count(page) == 0) > in put_page_testzero() in find_get_entries() during shmem_evict_inode(). > So, something not quite right with the refcounting when under pressure. I suspect some race with split_huge_page(), but don't see it so far. > My third impression was much better, when I just did a straight > cp /dev/zero /tmpfs_twice_size_of_RAM: that went smoothly, > pushed into swap just as it should, nice. > > > > > The main difference with Hugh's approach[1] is that I continue with > > compound pages, where Hugh invents new way couple pages: team pages. > > I believe THP refcounting rework made team pages unnecessary: compound > > page are flexible enough to serve needs of page cache. > > I have disagreed with you about the suitability of compound pages; > but at some point on Sunday night, after reading your patchset, > found myself looking at it differently, and now agreeing with you. > > They are not flexible enough yet, but I believe you have done a large > part of the work (by diverting all those tail ops to the head), and it > just needs a little more. I say "a little", but it might not be easy. > > What I realize now, is that you should be able to do almost everything > I did with team pages, instead with your compound pages. Just abandon > the idea that the whole compound page has to be initialized in one go: > initialize (charge to memcg, add to page cache, fill, SetPageUptodate) > each subpage as it is touched. (But of course, the whole extent has > to be to be initialized before it can be pmd-mapped.) I'm not convinced, that doing such operations on per-4k is better. All-at-once is simpler and has natural performance benefit from batching. I think we can switch some operations to per-4k basis once upside will be obvious. It's more on optimization side. > And the convenient thing about a compound page is that you have plenty > of space to hold your metadata: where I have been squeezing everything > into page->private (which makes it difficult then to extend the same > design to miscellaneous filesystems), you're free to use (certain) > fields of 511 more struct pages. > > I said above that you should be able to do almost everything: I think > that "almost" involves dropping a few things that I have, that we can > well do without. With team pages, it is possible for each member to > be charged to a different memcg; but I don't have anyone calling out > for that behaviour, it's more an awkward possibility that we have to > be on guard against in a few places, and I'd be quite happy just to > stop it (charging instead to whichever memcg first touched the extent). > > And it's been nice to entertain the idea of the individual team tails, > travelling separately up and down their own lrus, subject to their own > pagesize access patterns even while the whole is pmd-mapped. But in > practice, we continue to throw them on the unevictable list once they > get in the way, with no attempt to bring them back when accessed > individually; so I think it's a nice idea that we can live without. > > And a compound page implementation would avoid the overhead I have, > of putting all those tails on lru in the first place. Exactly. LRU scanning is one of places where this kind of batching is beneficial. > Another thing I did, that I think you can safely fail to emulate: > I was careful to allow sparse population, and not insist that the > head page be instantiated. That might turn out to be more of a > problem for compound pages, and has been an awkward edge case for me. > Although in principle there are sparse files which would be doubled > in charge by insisting that the head be instantiated, I doubt they > wil
Re: [PATCH 1/1] perf tools: Fix build break on powerpc
Em Sun, Mar 27, 2016 at 01:19:03PM +0200, Jiri Olsa escreveu:
> On Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu wrote:
> > From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu
> > Date: Sat, 26 Mar 2016 17:31:39 -0400
> > Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> > kernel sources")' seems to have accidentially removed the inclusion of
> > "util/header.h" from "arch/powerpc/util/header.c".
> >
> > "util/header.h" provides the prototype for get_cpuid() and is needed to
> > build perf on Powerpc.
> >
> > arch/powerpc/util/header.c:17:1: error: no previous prototype for
> > ‘get_cpuid’ [-Werror=missing-prototypes]
> >
> > Reported-by: Michael Ellerman
> > Signed-off-by: Sukadev Bhattiprolu
> > ---
> > tools/perf/arch/powerpc/util/header.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/perf/arch/powerpc/util/header.c
> > b/tools/perf/arch/powerpc/util/header.c
> > index 6138bde..5111e34 100644
> > --- a/tools/perf/arch/powerpc/util/header.c
> > +++ b/tools/perf/arch/powerpc/util/header.c
> > @@ -4,6 +4,7 @@
> > #include
> > #include
> > #include
> > +#include "../../util/header.h"
>
> you could use just "header.h" right?
Like this? I'm trying to find a way to do ppc cross builds, one more
thing to have in the build-tests...
commit 150da025b7f135450ca833fb80d54d59f0ddf185
Author: Sukadev Bhattiprolu
Date: Mon Mar 28 09:31:41 2016 -0300
perf tools: Fix build break on powerpc
Commit 531d2410635c ("perf tools: Do not include stringify.h from the
kernel sources") seems to have accidentially removed the inclusion of
"util/header.h" from "arch/powerpc/util/header.c".
"util/header.h" provides the prototype for get_cpuid() and is needed to
build perf on Powerpc:
arch/powerpc/util/header.c:17:1: error: no previous prototype for
‘get_cpuid’ [-Werror=missing-prototypes]
Reported-by: Michael Ellerman
Fixes: 531d2410635c ("perf tools: Do not include stringify.h from the
kernel sources")
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Arnaldo Carvalho de Melo
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index 6138bdef6e63..6de1a93241ae 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include "header.h"
#define mfspr(rn) ({unsigned long rval; \
asm volatile("mfspr %0," __stringify(rn) \
Re: [PATCH 00/23] Nokia N950 display support
Hi Sebastian, On 9 March 2016 at 17:09, Sebastian Reichel wrote: > Hi Emil, > > On Wed, Mar 09, 2016 at 04:19:48PM +, Emil Velikov wrote: >> Hi Sebastian, >> >> On 8 March 2016 at 16:39, Sebastian Reichel wrote: >> >> > arch/arm/boot/dts/omap3-n950-n9.dtsi| 72 + >> > arch/arm/boot/dts/omap3-n950.dts| 71 + >> Just a friendly reminder that updating these and one will have to keep >> the driver backwards compatible forever. > > Of course. Basically the new DT properties are: > > * optional regulators (vpnl & vddi) > * boolean "has-dsi-backlight" > * resolution-x/y > * offset-x/y > > So probably not that much of a problem even if other API is > invented. I just noticed, that I forgot to actually add documentation > in Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt > > I will fix that in the next patchset revision. > >> Tomi, has been in the process of removing all the unneeded cruft, >> although omapdrm it is still using the custom panel, dsi and other >> code as opposed to the ones provided by DRM. As he gets to reusing >> those he might have some fun keeping things compatible. > > I could not find "generic" panel binding documentation. Can you > give me a pointer? I can just stick to the same property names > to avoid potential future problems. > Pardon for the late reply. As mentioned in another email, if you're interested in reusing the drm panel infrastructure you should be looking in Documentation/devicetree/bindings/display/panel/. With display-timing panel-dpi panel-dsi-cm and (optional) simple-panel as a start. Would reshuffling/documenting things make it more obvious ? Feel free to let Rob Herring, Thierry Reding know. Regards, Emil
Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables
Hi Paul, The dmi_remap() is arch dependent function and for mainline used as ioremap_cache for x86, arm.. And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking about k4.5. It's rather bug of dmi_remap than the patch which just use it. The only reason why the bug wasn't found earlier it was unmapped back at init, but it doesn't mean it cannot be used after init, which can lead to strange behavior in future. If it should be ioremap_cache(), it's better to change dmi_remap() for your arch. Oh, yes, k4.2 is using the ioremap instead of ioremap_cache(). But seems it's currently solved with: commit ce1143aa60273220a9f89012f2aaaed04f97e9a2 "x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()" So, probably, it should be back ported. On 28.03.16 11:44, Paul Menzel wrote: Dear Ivan, dear Jeann, There is an unwanted regression due to commit d7f96f97 (firmware: dmi_scan: add SBMIOS entry and DMI tables). Since Linux kernel 4.2 the utility `cbmem`, used to access information stored in memory, from the coreboot project [1] does not work anymore on a lot of systems as reported in coreboot’s issue tracker as ticket #33 [2]. ``` Failed to mmap /dev/mem: Resource temporarily unavailable ``` Aaron Durbin analyzed on the coreboot mailing list [3]: 3) Why is that range set as uncached-minus? Would write-back work? Please see this thread: http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html The actual issue stems from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f which maintains a persistent mapping of smbios tables. It uses dmi_remap() which is '#define dmi_remap ioremap' which is where the uncached-minus PAT entry comes from. It should be using the same mechanism as the ACPI table mappings which uses ioremap_cache(). It’d be great, if the commit could be reverted, or the code be changed in a way that `cbmem` still works. If I should report this issue somewhere else, please tell me too, and I’ll do my best to follow up there. Thanks, Paul [1] https://www.coreboot.org [2] https://ticket.coreboot.org/issues/33 [3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html
Re: ARC dw-mshc binding compat string
On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung wrote:
> Hi,
>
> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>> Hi Marek, Vladimir,
>>
>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
On 26.03.2016 21:52, Marek Vasut wrote:
>
> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>
>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
Hi Marek,
On 26.03.2016 19:30, Marek Vasut wrote:
>
> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>
>>> Hi!
>>>
>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix
>>> in
>>> the DT compatible string:
>>>
>>> mmc@0x15000 {
>>> compatible = "altr,socfpga-dw-mshc";
>>> reg = < 0x15000 0x400 >;
>>> num-slots = < 1 >;
>>> fifo-depth = < 16 >;
>>> card-detect-delay = < 200 >;
>>> clocks = <&apbclk>, <&mmcclk>;
>>> clock-names = "biu", "ciu";
>>> interrupts = < 7 >;
>>> bus-width = < 4 >;
>>> };
>>>
>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>> should be extended with another compatibility string, something like
>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>> accordingly. What do you think ?
>>>
>> There is "snps,dw-mshc" described in
>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and
>> supported by
>> dw_mmc host controller driver.
> Thanks, that's even better.
>
> btw what do you think of using altr, prefix on non-altera system, that
> doesn't seem ok, right ?
according to ePAPR the prefix should represent a device (IP block here
I believe) manufacturer, so it should be okay to use "altr" prefix on
non-Altera system, if Altera provides another hardware vendor with
some own IP block.
>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>> chip makers (Altera etc).
>> Correct.
>>
>>>
That said, I would rather prefer to see "snps,dw-mshc" prefix on
description
of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc"
seems
to be redundant.
>
> Yes..it's redundant..i should be combined to "snps,dw-mshc".
socfpga is done correctly, IMO.
>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit
>>> ?
>>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
I meant to add a new property, not a new compatible, but that's just
my experience.
Let me say it __might__ happen that a particular change you need is
specific to a particular version of the DWMMC IP (query Synopsys
by the way), but more probably it might be e.g. the same IP version with
a different reduced or extended configuration or a minor fix/improvement
to the IP block without resulting version number bump.
For example I don't remember that errata fixes in IP blocks result in
a new compatible, instead there are quite common optional "quirk"
properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
>
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the
> below things.
>
> If Card is SDR50/SDR104/DDR50 mode..
>
