RE: linux-next: manual merge of the clockevents tree with the arm-soc tree
> Subject: linux-next: manual merge of the clockevents tree with the arm-soc
> tree
>
> Hi Daniel,
>
> Today's linux-next merge of the clockevents tree got a conflict in
> arch/arm/boot/dts/vf610.dtsi between commit 0517fe6aa880 ("ARM: dts:
> vf610-twr: Add support for sdhc1") from the arm-soc tree and commit
> 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer
> node") from the clockevents tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Acked-by: Xiubo Li
Thanks,
BRs
Xiubo
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc arch/arm/boot/dts/vf610.dtsi
> index 73355ddc5186,3c91b84066a1..
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@@ -360,17 -347,19 +360,30 @@@
> status = "disabled";
> };
>
> +esdhc1: esdhc@400b2000 {
> +compatible = "fsl,imx53-esdhc";
> +reg = <0x400b2000 0x4000>;
> +interrupts = <0 28 0x04>;
> +clocks = < VF610_CLK_IPG_BUS>,
> +< VF610_CLK_PLATFORM_BUS>,
> +< VF610_CLK_ESDHC1>;
> +clock-names = "ipg", "ahb", "per";
> +status = "disabled";
> +};
> +
> + ftm: ftm@400b8000 {
> + compatible = "fsl,ftm-timer";
> + reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
> + interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "ftm-evt", "ftm-src",
> + "ftm-evt-counter-en",
> "ftm-src-counter-en";
> + clocks = < VF610_CLK_FTM2>,
> + < VF610_CLK_FTM3>,
> + < VF610_CLK_FTM2_EXT_FIX_EN>,
> + < VF610_CLK_FTM3_EXT_FIX_EN>;
> + status = "disabled";
> + };
> +
> fec0: ethernet@400d {
> compatible = "fsl,mvf600-fec";
> reg = <0x400d 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 1/4] mfd: intel_soc_pmic: Core driver
On 5/24/2014 1:49 AM, Mark Brown wrote:
> On Fri, May 23, 2014 at 08:40:26AM +0800, Zhu, Lejun wrote:
>
>> +struct device *intel_soc_pmic_dev(void)
>> +{
>> +return pmic->dev;
>> +}
>> +EXPORT_SYMBOL(intel_soc_pmic_dev);
>
> Why do you need to take a global reference to this?
It was used by the GPIO driver to get the parent device. The latest
patch use dev.parent instead, so the whole function can be removed.
>> +/*
>> + * Read from a PMIC register
>> + */
>> +int intel_soc_pmic_readb(int reg)
>> +{
>> +int ret;
>> +unsigned int val;
>> +
>> +mutex_lock(_lock);
>> +
>> +if (!pmic) {
>> +ret = -EIO;
>> +} else {
>> +ret = regmap_read(pmic->regmap, reg, );
>> +if (!ret)
>> +ret = val;
>> +}
>> +
>> +mutex_unlock(_lock);
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL(intel_soc_pmic_readb);
>
> This is wrapping the EXPORT_SYMBOL_GPL() regmap API with an
> EXPORT_SYMBOL() API. Don't do that, if you really do need these
> wrappers make them EXPORT_SYMBOL_GPL().
I'll change them to use EXPORT_SYMBOL_GPL().
> There should also be no need to add extra locking around regmap calls,
> the regmap API has locking as standard.
Actually it also protects the pmic variable, so it won't be set to NULL
while there's ongoing read/write.
> It's also not clear why this API exists at all, surely all the
> interaction with the device happens from the core or function drivers
> for the device which ought to be able to get a direct reference to the
> regmap anyway and only be instantiated when one is present.
We created these names to hide the implementation of how read/write is
done from other platform specific patches interacting with this driver.
So when we change the implementation, e.g. from I2C read/write to
regmap, we don't have to touch all these patches.
>> +/*
>> + * Set platform_data of the child devices. Needs to be called before
>> + * the MFD device is added.
>> + */
>> +int intel_soc_pmic_set_pdata(const char *name, void *data, int len)
(...)
>> +EXPORT_SYMBOL(intel_soc_pmic_set_pdata);
>
> What is going on here, why aren't the normal ways of getting data to the
> devices (such as reading the platform data of the parent device) OK?
For this PMIC (Crystal Cove) it is not used. So I'll remove it.
>> +static void __pmic_regmap_flush(void)
>> +{
>> +if (cache_write_pending)
>> +WARN_ON(regmap_write(pmic->regmap, cache_offset,
>> + cache_write_val));
>
>> +static int pmic_regmap_load_from_hw(struct intel_pmic_regmap *map)
>> +{
>> +int ret;
>
> This all appears to be an open coded cache layer - there is already
> cache support in regmap, just reuse that.
>
>> +static irqreturn_t pmic_irq_isr(int irq, void *data)
>> +{
>> +return IRQ_WAKE_THREAD;
>> +}
>
> Just register the IRQ as IRQF_ONESHOT and only provide the threaded
> handler.
I'll fix it.
>> +static irqreturn_t pmic_irq_thread(int irq, void *data)
>> +{
>> +int i;
>> +
>> +mutex_lock(>irq_lock);
>> +
>> +for (i = 0; i < pmic->irq_num; i++) {
>> +if (test_bit(PMIC_IRQ_MASK_BIT(i), _IRQ_MASK(pmic, i)))
>> +continue;
>> +
>> +if (pmic_regmap_read(>irq_regmap[i].status)) {
>> +pmic_regmap_write(>irq_regmap[i].ack, 1);
>> +handle_nested_irq(pmic->irq_base + i);
>> +}
>> +}
>
> This looks like you should be using regmap-irq, or at least like there's
> some small additions needed to make it usable.
I'll check if I can convert to regmap-irq. If it works, I won't need
this and the cache layer.
>> +if (gpio_is_valid(pmic->pmic_int_gpio)) {
>> +ret = gpio_request_one(pmic->pmic_int_gpio,
>> + GPIOF_DIR_IN, "PMIC Interupt");
>> +if (ret) {
>> +dev_err(pmic->dev, "Request PMIC_INT gpio error\n");
>> +goto out_free_desc;
>> +}
>> +
>> +pmic->irq = gpio_to_irq(pmic->pmic_int_gpio);
>> +}
>
> There should be no need to do this, simply requesting the interrupt
> should be sufficient to ensure the pin is in the correct mode. If this
> isn't the case the interrupt controller driver probably needs an update,
> there's some support for helping with this in the GPIO framework IIRC.
I'll remove this.
> You're also not using managed (devm) allocations for anything here.
Best Regards
Lejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 1/4] mfd: intel_soc_pmic: Core driver
On 5/24/2014 1:49 AM, Mark Brown wrote:
On Fri, May 23, 2014 at 08:40:26AM +0800, Zhu, Lejun wrote:
+struct device *intel_soc_pmic_dev(void)
+{
+return pmic-dev;
+}
+EXPORT_SYMBOL(intel_soc_pmic_dev);
Why do you need to take a global reference to this?
It was used by the GPIO driver to get the parent device. The latest
patch use dev.parent instead, so the whole function can be removed.
+/*
+ * Read from a PMIC register
+ */
+int intel_soc_pmic_readb(int reg)
+{
+int ret;
+unsigned int val;
+
+mutex_lock(pmic_lock);
+
+if (!pmic) {
+ret = -EIO;
+} else {
+ret = regmap_read(pmic-regmap, reg, val);
+if (!ret)
+ret = val;
+}
+
+mutex_unlock(pmic_lock);
+
+return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_readb);
This is wrapping the EXPORT_SYMBOL_GPL() regmap API with an
EXPORT_SYMBOL() API. Don't do that, if you really do need these
wrappers make them EXPORT_SYMBOL_GPL().
I'll change them to use EXPORT_SYMBOL_GPL().
There should also be no need to add extra locking around regmap calls,
the regmap API has locking as standard.
Actually it also protects the pmic variable, so it won't be set to NULL
while there's ongoing read/write.
It's also not clear why this API exists at all, surely all the
interaction with the device happens from the core or function drivers
for the device which ought to be able to get a direct reference to the
regmap anyway and only be instantiated when one is present.
We created these names to hide the implementation of how read/write is
done from other platform specific patches interacting with this driver.
So when we change the implementation, e.g. from I2C read/write to
regmap, we don't have to touch all these patches.
+/*
+ * Set platform_data of the child devices. Needs to be called before
+ * the MFD device is added.
+ */
+int intel_soc_pmic_set_pdata(const char *name, void *data, int len)
(...)
+EXPORT_SYMBOL(intel_soc_pmic_set_pdata);
What is going on here, why aren't the normal ways of getting data to the
devices (such as reading the platform data of the parent device) OK?
For this PMIC (Crystal Cove) it is not used. So I'll remove it.
+static void __pmic_regmap_flush(void)
+{
+if (cache_write_pending)
+WARN_ON(regmap_write(pmic-regmap, cache_offset,
+ cache_write_val));
+static int pmic_regmap_load_from_hw(struct intel_pmic_regmap *map)
+{
+int ret;
This all appears to be an open coded cache layer - there is already
cache support in regmap, just reuse that.
+static irqreturn_t pmic_irq_isr(int irq, void *data)
+{
+return IRQ_WAKE_THREAD;
+}
Just register the IRQ as IRQF_ONESHOT and only provide the threaded
handler.
I'll fix it.
+static irqreturn_t pmic_irq_thread(int irq, void *data)
+{
+int i;
+
+mutex_lock(pmic-irq_lock);
+
+for (i = 0; i pmic-irq_num; i++) {
+if (test_bit(PMIC_IRQ_MASK_BIT(i), PMIC_IRQ_MASK(pmic, i)))
+continue;
+
+if (pmic_regmap_read(pmic-irq_regmap[i].status)) {
+pmic_regmap_write(pmic-irq_regmap[i].ack, 1);
+handle_nested_irq(pmic-irq_base + i);
+}
+}
This looks like you should be using regmap-irq, or at least like there's
some small additions needed to make it usable.
I'll check if I can convert to regmap-irq. If it works, I won't need
this and the cache layer.
+if (gpio_is_valid(pmic-pmic_int_gpio)) {
+ret = gpio_request_one(pmic-pmic_int_gpio,
+ GPIOF_DIR_IN, PMIC Interupt);
+if (ret) {
+dev_err(pmic-dev, Request PMIC_INT gpio error\n);
+goto out_free_desc;
+}
+
+pmic-irq = gpio_to_irq(pmic-pmic_int_gpio);
+}
There should be no need to do this, simply requesting the interrupt
should be sufficient to ensure the pin is in the correct mode. If this
isn't the case the interrupt controller driver probably needs an update,
there's some support for helping with this in the GPIO framework IIRC.
I'll remove this.
You're also not using managed (devm) allocations for anything here.
Best Regards
Lejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 2/4] mfd: intel_soc_pmic: I2C interface
On 5/24/2014 1:53 AM, Mark Brown wrote:
On Fri, May 23, 2014 at 08:40:27AM +0800, Zhu, Lejun wrote:
+static int pmic_i2c_lookup_gpio(struct device *dev, int acpi_index)
+{
+struct gpio_desc *desc;
+int gpio;
+
+desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+if (IS_ERR(desc))
+return PTR_ERR(desc);
+
+gpio = desc_to_gpio(desc);
+
+gpiod_put(desc);
+
+return gpio;
+}
Why not just have the driver work with the gpiod API, is there any real
need to convert to a GPIO number?
The whole function will be removed since the gpio set code is removed
during probe.
+static const struct i2c_device_id pmic_i2c_id[] = {
+{ crystal_cove, (kernel_ulong_t)crystal_cove_pmic},
+{ INT33FD, (kernel_ulong_t)crystal_cove_pmic},
+{ INT33FD:00, (kernel_ulong_t)crystal_cove_pmic},
+{ }
+};
+MODULE_DEVICE_TABLE(i2c, pmic_i2c_id);
The INT33FD ones here look like they should only be in the ACPI table.
You are right. Only INT33FD:00 should be here.
+static int __init pmic_i2c_init(void)
+{
+int ret;
+
+ret = i2c_add_driver(pmic_i2c_driver);
+if (ret != 0)
+pr_err(Failed to register pmic I2C driver: %d\n, ret);
+
+return ret;
+}
+subsys_initcall(pmic_i2c_init);
module_i2c_driver() - you shouldn't need subsys_initcall().
I'll change it to module_init.
Best Regards
Lejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: manual merge of the clockevents tree with the arm-soc tree
Subject: linux-next: manual merge of the clockevents tree with the arm-soc
tree
Hi Daniel,
Today's linux-next merge of the clockevents tree got a conflict in
arch/arm/boot/dts/vf610.dtsi between commit 0517fe6aa880 (ARM: dts:
vf610-twr: Add support for sdhc1) from the arm-soc tree and commit
07513e1330a9 (ARM: dts: vf610: Add Freescale FlexTimer Module timer
node) from the clockevents tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Acked-by: Xiubo Li li.xi...@freescale.com
Thanks,
BRs
Xiubo
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/vf610.dtsi
index 73355ddc5186,3c91b84066a1..
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@@ -360,17 -347,19 +360,30 @@@
status = disabled;
};
+esdhc1: esdhc@400b2000 {
+compatible = fsl,imx53-esdhc;
+reg = 0x400b2000 0x4000;
+interrupts = 0 28 0x04;
+clocks = clks VF610_CLK_IPG_BUS,
+clks VF610_CLK_PLATFORM_BUS,
+clks VF610_CLK_ESDHC1;
+clock-names = ipg, ahb, per;
+status = disabled;
+};
+
+ ftm: ftm@400b8000 {
+ compatible = fsl,ftm-timer;
+ reg = 0x400b8000 0x1000 0x400b9000 0x1000;
+ interrupts = 0 44 IRQ_TYPE_LEVEL_HIGH;
+ clock-names = ftm-evt, ftm-src,
+ ftm-evt-counter-en,
ftm-src-counter-en;
+ clocks = clks VF610_CLK_FTM2,
+ clks VF610_CLK_FTM3,
+ clks VF610_CLK_FTM2_EXT_FIX_EN,
+ clks VF610_CLK_FTM3_EXT_FIX_EN;
+ status = disabled;
+ };
+
fec0: ethernet@400d {
compatible = fsl,mvf600-fec;
reg = 0x400d 0x1000;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: inotify, new idea?
On 05/24/2014 02:34 PM, Richard Weinberger wrote: Am 24.05.2014 09:52, schrieb Michael Kerrisk (man-pages): On 04/21/2014 10:42 AM, Richard Weinberger wrote: Am 21.04.2014 09:24, schrieb Michael Kerrisk: Does recursive monitoring even work with inotify? Last time I've tried it did failed as soon I did a mkdir -p a/b/c/d because mkdir() raced against the thread which installes the new watches. As I understand it, you have to program to deal with the races (rescan directories after adding watches). I recently did a lot of work updating the inotify(7) man page to discuss all the issues that I know of, and their remedies. If I missed anything, I'd appreciate a note on it, so that it can be added. See http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES I'm aware of the rescan hack, but in my case it does not help because my program must not miss any event. Currently I'm using a fuse overlay filesystem to log everything. Not perfect but works... :-) Richard, A late follow up question. How does your application deal with the event overflow problem (i.e., when you get a large number of events much faster than your application can deal with them? The downside of the FUSE approach is that you have to intercept every filesystem function. This can be a performance issue. But due to this design the overflow problem cannot happen as the FUSE filesystem blocks until the event has been proceed. Ahh -- that clears things up for me. Thanks, Richard. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the clockevents tree
Hi Daniel, After merging the clockevents tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/clocksource/timer-sun5i.c: In function 'sun5i_timer_init': drivers/clocksource/timer-sun5i.c:167:2: error: implicit declaration of function 'of_reset_control_get' [-Werror=implicit-function-declaration] Caused by commit e50a00be5c42 (clocksource: sun5i: Add support for reset controller). I have used the clockevents tree from next-20140523 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
RE: [f2fs-dev] [PATCH] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
Hi Kim,
-Original Message-
From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
Sent: Wednesday, May 21, 2014 11:37 AM
To: Chao Yu
Cc: Jaegeuk Kim; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace
f2fs_submit_page_mbio event in
ra_sum_pages
Hi Chao,
2014-05-16 (금), 17:14 +0800, Chao Yu:
Previously we allocate pages with no mapping in ra_sum_pages(), so we may
encounter a crash in event trace of f2fs_submit_page_mbio where we access
mapping data of the page.
We'd better allocate pages in bd_inode mapping and invalidate these pages
after
we restore data from pages. It could avoid crash in above scenario.
Call Trace:
[f1031630] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
[f10377bb] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
[f103c5da] restore_node_summary+0x13a/0x280 [f2fs]
[f103e22d] build_curseg+0x2bd/0x620 [f2fs]
[f104043b] build_segment_manager+0x1cb/0x920 [f2fs]
[f1032c85] f2fs_fill_super+0x535/0x8e0 [f2fs]
[c115b66a] mount_bdev+0x16a/0x1a0
[f102f63f] f2fs_mount+0x1f/0x30 [f2fs]
[c115c096] mount_fs+0x36/0x170
[c1173635] vfs_kern_mount+0x55/0xe0
[c1175388] do_mount+0x1e8/0x900
[c1175d72] SyS_mount+0x82/0xc0
[c16059cc] sysenter_do_call+0x12/0x22
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/node.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3d60d3d..b5cd814 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1658,13 +1658,16 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
struct page *page)
/*
* ra_sum_pages() merge contiguous pages into one bio and submit.
- * these pre-readed pages are linked in pages list.
+ * these pre-readed pages are alloced in bd_inode's mapping tree.
*/
-static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head *pages,
+static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
int start, int nrpages)
{
struct page *page;
+ struct inode *inode = sbi-sb-s_bdev-bd_inode;
+ struct address_space *mapping = inode-i_mapping;
int page_idx = start;
+ int alloced, readed;
struct f2fs_io_info fio = {
.type = META,
.rw = READ_SYNC | REQ_META | REQ_PRIO
@@ -1672,21 +1675,23 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi,
struct list_head
*pages,
for (; page_idx start + nrpages; page_idx++) {
/* alloc temporal page for read node summary info*/
- page = alloc_page(GFP_F2FS_ZERO);
+ page = grab_cache_page(mapping, page_idx);
if (!page)
break;
-
- lock_page(page);
- page-index = page_idx;
- list_add_tail(page-lru, pages);
+ page_cache_release(page);
IMO, we don't need to do like this.
Instead,
for() {
page = grab_cache_page();
if (!page)
break;
page[page_idx] = page;
f2fs_submit_page_mbio(sbi, page, fio);
}
f2fs_submit_merged_bio(sbi, META, READ);
return page_idx - start;
Agreed, it helps to remove a lot of redundant code here.
Thanks!
Afterwards, in restore_node_summry(),
lock_page() will wait the end_io for read.
...
f2fs_put_page(pages[index], 1);
Thanks,
}
- list_for_each_entry(page, pages, lru)
- f2fs_submit_page_mbio(sbi, page, page-index, fio);
+ alloced = page_idx - start;
+ readed = find_get_pages_contig(mapping, start, alloced, pages);
+ BUG_ON(alloced != readed);
+
+ for (page_idx = 0; page_idx readed; page_idx++)
+ f2fs_submit_page_mbio(sbi, pages[page_idx],
+ pages[page_idx]-index, fio);
f2fs_submit_merged_bio(sbi, META, READ);
- return page_idx - start;
+ return readed;
}
int restore_node_summary(struct f2fs_sb_info *sbi,
@@ -1694,11 +1699,11 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
{
struct f2fs_node *rn;
struct f2fs_summary *sum_entry;
- struct page *page, *tmp;
+ struct inode *inode = sbi-sb-s_bdev-bd_inode;
block_t addr;
int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
- int i, last_offset, nrpages, err = 0;
- LIST_HEAD(page_list);
+ struct page *pages[bio_blocks];
+ int i, index, last_offset, nrpages, err = 0;
/* scan the node segment */
last_offset = sbi-blocks_per_seg;
@@ -1709,29 +1714,31 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
nrpages = min(last_offset - i, bio_blocks);
/* read ahead node pages */
- nrpages = ra_sum_pages(sbi, page_list, addr, nrpages);
RE: [f2fs-dev] [PATCH] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
Hi changman,
-Original Message-
From: Changman Lee [mailto:cm224@samsung.com]
Sent: Friday, May 23, 2014 1:14 PM
To: Jaegeuk Kim
Cc: Chao Yu; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace
f2fs_submit_page_mbio event in
ra_sum_pages
On Wed, May 21, 2014 at 12:36:46PM +0900, Jaegeuk Kim wrote:
Hi Chao,
2014-05-16 (금), 17:14 +0800, Chao Yu:
Previously we allocate pages with no mapping in ra_sum_pages(), so we may
encounter a crash in event trace of f2fs_submit_page_mbio where we access
mapping data of the page.
We'd better allocate pages in bd_inode mapping and invalidate these pages
after
we restore data from pages. It could avoid crash in above scenario.
Call Trace:
[f1031630] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
[f10377bb] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
[f103c5da] restore_node_summary+0x13a/0x280 [f2fs]
[f103e22d] build_curseg+0x2bd/0x620 [f2fs]
[f104043b] build_segment_manager+0x1cb/0x920 [f2fs]
[f1032c85] f2fs_fill_super+0x535/0x8e0 [f2fs]
[c115b66a] mount_bdev+0x16a/0x1a0
[f102f63f] f2fs_mount+0x1f/0x30 [f2fs]
[c115c096] mount_fs+0x36/0x170
[c1173635] vfs_kern_mount+0x55/0xe0
[c1175388] do_mount+0x1e8/0x900
[c1175d72] SyS_mount+0x82/0xc0
[c16059cc] sysenter_do_call+0x12/0x22
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/node.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3d60d3d..b5cd814 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1658,13 +1658,16 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
struct page *page)
/*
* ra_sum_pages() merge contiguous pages into one bio and submit.
- * these pre-readed pages are linked in pages list.
+ * these pre-readed pages are alloced in bd_inode's mapping tree.
*/
-static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head
*pages,
+static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
int start, int nrpages)
{
struct page *page;
+ struct inode *inode = sbi-sb-s_bdev-bd_inode;
How about use sbi-meta_inode instead of bd_inode, then we can do
caching summary pages for further i/o.
In my understanding, In ra_sum_pages() we readahead node pages in NODE segment,
then we could padding current summary caching with nid of node page's footer.
So we should not cache this readaheaded pages in meta_inode's mapping.
Do I miss something?
Regards
+ struct address_space *mapping = inode-i_mapping;
int page_idx = start;
+ int alloced, readed;
struct f2fs_io_info fio = {
.type = META,
.rw = READ_SYNC | REQ_META | REQ_PRIO
@@ -1672,21 +1675,23 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi,
struct list_head
*pages,
for (; page_idx start + nrpages; page_idx++) {
/* alloc temporal page for read node summary info*/
- page = alloc_page(GFP_F2FS_ZERO);
+ page = grab_cache_page(mapping, page_idx);
if (!page)
break;
-
- lock_page(page);
- page-index = page_idx;
- list_add_tail(page-lru, pages);
+ page_cache_release(page);
IMO, we don't need to do like this.
Instead,
for() {
page = grab_cache_page();
if (!page)
break;
page[page_idx] = page;
f2fs_submit_page_mbio(sbi, page, fio);
}
f2fs_submit_merged_bio(sbi, META, READ);
return page_idx - start;
Afterwards, in restore_node_summry(),
lock_page() will wait the end_io for read.
...
f2fs_put_page(pages[index], 1);
Thanks,
}
- list_for_each_entry(page, pages, lru)
- f2fs_submit_page_mbio(sbi, page, page-index, fio);
+ alloced = page_idx - start;
+ readed = find_get_pages_contig(mapping, start, alloced, pages);
+ BUG_ON(alloced != readed);
+
+ for (page_idx = 0; page_idx readed; page_idx++)
+ f2fs_submit_page_mbio(sbi, pages[page_idx],
+ pages[page_idx]-index, fio);
f2fs_submit_merged_bio(sbi, META, READ);
- return page_idx - start;
+ return readed;
}
int restore_node_summary(struct f2fs_sb_info *sbi,
@@ -1694,11 +1699,11 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
{
struct f2fs_node *rn;
struct f2fs_summary *sum_entry;
- struct page *page, *tmp;
+ struct inode *inode = sbi-sb-s_bdev-bd_inode;
block_t addr;
int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
- int i, last_offset, nrpages, err = 0;
- LIST_HEAD(page_list);
+ struct page
Re: [RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()'
On 23 May 2014 21:44, Sören Brinkmann soren.brinkm...@xilinx.com wrote: Viresh: Could you imagine something similar for cpufreq? You suggested migrating to Hz resolution. I guess that would ideally mean to follow the CCF to a 64-bit type for frequencies and increasing the resolution. I have a messy patch migrating cpufreq and OPP to Hz and unsigned long that works on Zynq. But cpufreq has so many users that it would become quite an undertaking. And we'd need some new/amended OPP DT binding. If we are going to migrate to Hz from KHz, I think we must consider the 64 bit stuff right now, otherwise it will bite us later. @Rafael: What do you think? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: Add pmu sysreg node to Exynos3250
This patch add pmusysreg node for Exynos3250 to access PMU (Power Management
Unit)
register in a centralized way using syscon driver.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
arch/arm/boot/dts/exynos3250.dtsi | 5 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index b562634..2a4ab04 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,6 +2,7 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+ - samsung,exynos3250-pmu - for Exynos3250 SoC,
- samsung,exynos4210-pmu - for Exynos4210 SoC,
- samsung,exynos4212-pmu - for Exynos4212 SoC,
- samsung,exynos4412-pmu - for Exynos4412 SoC,
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index ca28eac..3e678fa 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -125,6 +125,11 @@
reg = 0x1001 0x400;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos3250-pmu, syscon;
+ reg = 0x1002 0x4000;
+ };
+
pd_cam: cam-power-domain@10023C00 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C00 0x20;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] slave-dmaengine fixes
Hi Linus,
Here is the pull request for slave dmaengine for 3.15. We have three small
fixes. First one from Andy reverts the devm_request irq as we need to ensure the
tasklet is killed after irq is freed, so we need to do free irq in our code.
Other two from Arnd are fixing the compilation issue in omap and sa11x0
drivers with ARM randconfigs
The following changes since commit a798c10faf62a505d24e5f6213fbaf904a39623f:
Linus Torvalds (1):
Linux 3.15-rc2
are available in the git repository at:
git://git.infradead.org/users/vkoul/slave-dma.git fixes
Andy Shevchenko (1):
dmaengine: dw: went back to plain {request,free}_irq() calls
Arnd Bergmann (2):
dmaengine: omap: hide filter_fn for built-in drivers
dmaengine: sa11x0: remove broken #ifdef
drivers/dma/dw/core.c| 11 ++-
drivers/dma/sa11x0-dma.c |4
include/linux/omap-dma.h |2 +-
3 files changed, 7 insertions(+), 10 deletions(-)
--
Thanks
~Vinod
signature.asc
Description: Digital signature
Re: [PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
On 05/24/2014 12:07 AM, Mike Turquette wrote: Quoting Nishanth Menon (2014-05-16 03:45:57) Hi, This patch series has been carried over in vendor kernel for quiet few years now. Unfortunately, it was very recently re-discovered and upstream kernel is noticed to be broken for OMAP5 1.5GHz - at least we are operating DPLL at frequency higher than what it was intended to be when CPUFreq is enabled. Thankfully, with nominal voltage(we dont use AVS yet in upstream for the mentioned platforms) and margins in trimming, we have so far not crashed - but I strongly suspect this might be some boundary case survival. DCC also exists in OMAP4. In some cases customers used it, in other cases we just ran the PLL way out of spec and the mpu_clk would divide by 2. Is this broken for OMAP4 as well? Yes, its broken. This series does not address the OMAP4 needs for it, but can be expanded later by just defining a proper clock type with OMAP4 specific DCC rate limits etc. for it. We would need properly functioning DVFS for OMAP4 panda first though I guess... (support for the TPS regulator.) -Tero Regards, Mike Verified on the following impacted platforms using 3.15-rc4 based vendor kernel. Before: OMAP5432: http://slexy.org/view/s20cs0qQFg DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) DRA75x: http://slexy.org/view/s20AW8MU5c After: OMAP5432: http://slexy.org/view/s21iAfWxpu DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) DRA75x: http://slexy.org/view/s21ehw8WQn Hopefully, we can get these into some kernel revision in some form. NOTE: Support for 4470(which is the only other platform requiring DCC) is not present in upstream kernel and there are no plans to support that SoC, even if it is added at a later point, support can be extended as needed. Series based on v3.15-rc5 tag. Also available on my tree: https://github.com/nmenon/linux-2.6-playground/ branch: push/clock/dcc weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc Verification: 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) Andrii Tseglytskyi (1): ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) Nishanth Menon (2): clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies .../devicetree/bindings/clock/ti/dpll.txt |1 + arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- arch/arm/mach-omap2/dpll3xxx.c |9 + drivers/clk/ti/dpll.c | 21 include/linux/clk/ti.h |4 6 files changed, 37 insertions(+), 2 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On 23.05.2014 17:40, Alex Courbot wrote: On 05/23/2014 06:59 PM, Lucas Stach wrote: So after checking with more knowledgeable people, it turns out this is the expected behavior on ARM and BAR regions should be mapped uncached on GK20A. All the more reasons to avoid using the BAR at all. This is actually specific to Tegra. You may want to make yourself aware of all the quirks required for sharing memory between the GPU and CPU on an ARM host. I think there are far more involved than what you see now and writing an replacement for TTM will not be an easy task. Doing away with the concept of two memory areas will not get you to a single unified address space. You would have to deal with things like not being able to change the caching state of pages in the systems lowmem yourself. You will still have to deal with remapping pages that aren't currently visible to the CPU (ok this is not an issue on Jetson right now as it only has 2GB of RAM), because it's in systems highmem, or even in a different LPAE area. You really want to be sure you are aware of all the consequences of this, before considering this task. Yep, that's why I am seeking advice here. My first hope is that with a few tweaks we will be able to keep using TTM and the current nouveau_bo implementation. But unless I missed something this is not going to be easy. We can also use something like the patch I originally sent to make it work, although not with good performance, on GK20A. Not very graceful, but it will allow applications to run. In the long run though, we will want to achieve better performance, and it seems like a BO implementation targeted at UMA devices would also be beneficial to quite a few desktop GPUs. So as tricky as it may be I'm interested in gathering thoughts and why not giving it a first try with GK20A, even if it imposes some limitations like having buffers in lowmem in a first time (we can probably live with this one for a short while, and 64 bits will also be coming to the rescue :)) I don't think lowmem or LPAE is any problem, if the memory manager is designed with that in mind. Vast majority of the buffers kernel allocates do not need to be touched in kernel space. Actually I can't think of any buffers that we allocate on behalf of user space that would need to be permanently mapped also to kernel. In case or relocs only push buffer needs to be temporarily mapped to kernel. Ultimately even relocs are not necessary if we expose GPU virtual addresses directly to user space. But that's another topic. Terje -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] mmc: add slot argument to mmc_of_parse
Hi,
Sorry I was on vacation, I'll send a cleaner patch updating other drivers
this week.
Regards
Ludovic
On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
Hi, All.
This patch is working on progress?
I want to merge this patch for fixing dw-mmc controller problem.
If this patch didn't work on progress, i will send the patch based-on this
patch.
Best Regards,
Jaehoon Chung
On 05/14/2014 06:53 PM, Ulf Hansson wrote:
On 7 May 2014 12:06, Ludovic Desroches ludovic.desroc...@atmel.com wrote:
Some hosts manage several slots. In these case information such as the bus
width, chip detect and others are into the slot node. So we have to parse
child nodes. If not NULL, slot node will be used instead of the device
node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
Hi,
Since this patch is only a RFC, I have not yet updated drivers using this
function.
I would like to use mmc_of_parse to reduce code duplication. My issue is
that
atmel mci is a bit different from others mci host since it can provide
several slots, so it allocates several mmc hosts. By the way, it is not the
only one.
When calling mmc_alloc_host, host-parent is set to pdev-dev.
mmc_of_parse
uses host-parent-of_node but in my case settings are in the slot nodes
so in
the child nodes. That's why I would like to have a way to tell which node I
want to use.
Seems reasonable, thanks for working on this!
Regards
Ludovic
drivers/mmc/core/host.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index fdea825..ed6cea5 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
/**
* mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot: some devices provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
--
1.7.9.5
How about adding a new API, __mmc_of_parse((struct mmc_host *host,
struct device_node *slot)
Then let the old API mmc_of_parse() remain as is, but let it call the
new API with slot == NULL.
Atmel can then use the new API, but the other drivers can remain as is.
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon wakeup regression in 3.15-rc6
On 25.05.2014 14:56, Woody Suwalski wrote: Malte Schröder wrote: Hi, I just tried 3.15-rc6. I encountered a pretty nasty problem, which is after suspending to RAM the system doesn't wake up properly. v3.14 is fine. On wakeup all seems fine, i.e. hd starts to spin an USB-stuff wakes up. But all I get from the graphics card is a white screen slowly filling with random colored pixels. I had to hard reset the system. I attached the kernel log, the X-servers log, lspci-output and my kernel config. Regards Malte I have seen a bit of a screen distortion at the bottom of LCD on Radeon after a wakeup. I tried to re-run with drm.debug=0x0e, however once I did it - the problem has disappeared, and I have not been able to duplicate it again. So just watching for now. OTOH I have seen (only one time) a black screen after wakeup on Nvidia. So maybe some timing is now exposed in PM / DRM... Woody I pulled git://people.freedesktop.org/~deathsimple/linux drm-fixes-3.15 from http://article.gmane.org/gmane.comp.video.dri.devel/106114 and my problem is gone ... -- Gruß Malte Schröder - malte...@gmx.de signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Mike, On 05/06/2014 04:31 PM, Nishanth Menon wrote: On 16:24-20140506, Peter Ujfalusi wrote: Hi, Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment Could you take a look at this series please? I really hoped that it would make it to 3.16... Thanks, Péter v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: ti,palmas-clk32kg for clk32kg clock ti,palmas-clk32kgaudio for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 1.9.2 Series: Reviewed-by: Nishanth Menon n...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inotify, new idea?
Am 26.05.2014 01:46, schrieb Marian Marinov: Have anyone of you looked at this: https://github.com/1and1/linux-filemon/ I haven't stress tested it, but in the past I ported it to more recent kernels: https://github.com/hackman/filemon-patches It is not polished, but it works. I'm considering fixing some of the issues at has for use in my home setup. Well, the patch itself has documented its major flaw: + * WARNING! This patch has been designed as EXPERIMENTAL. Its usage + * is DANGEROUS, because some filesystems could get exhausted by the + * masses of ORPHAN INODES! Thanks, //richard signature.asc Description: OpenPGP digital signature
[RESEND PATCH 2/2] power: max8925: Use of_get_child_by_name
Use of_get_child_by_name to obtain reference to charger node instead of
of_find_node_by_name which can walk outside of the parent node.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/power/max8925_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index 0cf237808d47..a6d45eef64dd 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -443,7 +443,7 @@ max8925_power_dt_init(struct platform_device *pdev)
if (!nproot)
return pdev-dev.platform_data;
- np = of_find_node_by_name(nproot, charger);
+ np = of_get_child_by_name(nproot, charger);
if (!np) {
dev_err(pdev-dev, failed to find charger node\n);
return NULL;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/2] power: max8925: Fix NULL ptr dereference on memory allocation failure
Check the return value of devm_kzalloc() to fix possible NULL pointer dereference and properly exit the probe() on memory allocation failure. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/power/max8925_power.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c index b4513f284bbc..0cf237808d47 100644 --- a/drivers/power/max8925_power.c +++ b/drivers/power/max8925_power.c @@ -452,13 +452,14 @@ max8925_power_dt_init(struct platform_device *pdev) pdata = devm_kzalloc(pdev-dev, sizeof(struct max8925_power_pdata), GFP_KERNEL); + if (!pdata) + goto ret; of_property_read_u32(np, topoff-threshold, topoff_threshold); of_property_read_u32(np, batt-detect, batt_detect); of_property_read_u32(np, fast-charge, fast_charge); of_property_read_u32(np, no-insert-detect, no_insert_detect); of_property_read_u32(np, no-temp-support, no_temp_support); - of_node_put(np); pdata-batt_detect = batt_detect; pdata-fast_charge = fast_charge; @@ -466,6 +467,8 @@ max8925_power_dt_init(struct platform_device *pdev) pdata-no_insert_detect = no_insert_detect; pdata-no_temp_support = no_temp_support; +ret: + of_node_put(np); return pdata; } #else -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 1/2] printk: Add context information to the header of /dev/kmsg
Hi Kay,
Thank you for your reply.
(2014/05/19 20:35), Kay Sievers wrote:
On Mon, May 19, 2014 at 7:28 PM, Yoshihiro YUNOMAE
yoshihiro.yunomae...@hitachi.com wrote:
Add context information to the header of /dev/kmsg.
Two printk messages connected with KERN_CONT can be divided in multiple lines
by a different process context message. If the different context message seems
like the 1st divided message, it is difficult to understand which the 2nd
divided message belongs to. This problem can also occur for the situation where
multiple message lines without KERN_CONT are broken into by similar messages.
For example, SCSI disk error messages can be show as follows:
[110781.736171] sd 2:0:0:0: [sdb]
[110781.736170] sd 3:0:0:0: [sdc] Unhandled sense code
[110781.736172] sd 3:0:0:0: [sdc]
[110781.736175] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[110781.736177] sd 3:0:0:0: [sdc]
[110781.736178] Sense Key : Medium Error [current]
[110781.736187] Sense Key : Recovered Error
[110781.736189] [current]
[...]
This patch adds PID and interrupt context flag to the header of /dev/kmsg as
the context information in order to understand relation of output messages. If
PID values of two messages and the interrupt context flags are same, it means
that those messages are same context, so those message have some relation. If
not so, it means that those messages are different context, so users do not
need to take care about the relation of the messages.
[...]
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -197,6 +197,8 @@ enum log_flags {
struct printk_log {
u64 ts_nsec;/* timestamp in nanoseconds */
+ pid_t pid; /* identify PID */
+ u32 irq_count; /* identify irq_count */
I don't think it is worth to blow-up this heavily used struct up even
more, just because SCSI cannot log in simple single calls. How about
fixing SCSI to log to a local buffer if it cannot safely print one
line at once.
I'm not convinced, that turning the /dev/kmsg format into an
annotation language', and requiring a rather complex state machine to
re-construct the broken logging makes too much sense here. If tools
rely on properly formatted logging messages, the logging should be
fixed at the source while it is logged, not be reconstructed later.
It is not not my call, but I don't this makes much sense. Continuation
lines are best effort not a facility that is or ever was reliable in
the past. I think the proper fix is how the log is created, not how it
is exported.
As we discussed about this issue in LinuxCon Japan, mixed messages will
be fixed in each subsystem. In the SCSI layer, tracing feature will be
used. (http://www.spinics.net/lists/linux-scsi/msg74428.html)
If we found the same issue in other subsystem, we would like to add
new generic printk API to avoid mixed messages.
Thank you,
Yoshihiro YUNOMAE
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] mmc: add slot argument to mmc_of_parse
Hi, Ludovic.
I have sent the patch based on your RFC patch..how about?
If you have the comment or other opinion, let me know, plz.
https://patchwork.kernel.org/patch/4230101/
It needs to use your suggestion at dw-mmc controller, so i have posted it.
Best Regards,
Jaehoon Chung
On 05/26/2014 04:03 PM, Ludovic Desroches wrote:
Hi,
Sorry I was on vacation, I'll send a cleaner patch updating other drivers
this week.
Regards
Ludovic
On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
Hi, All.
This patch is working on progress?
I want to merge this patch for fixing dw-mmc controller problem.
If this patch didn't work on progress, i will send the patch based-on this
patch.
Best Regards,
Jaehoon Chung
On 05/14/2014 06:53 PM, Ulf Hansson wrote:
On 7 May 2014 12:06, Ludovic Desroches ludovic.desroc...@atmel.com wrote:
Some hosts manage several slots. In these case information such as the bus
width, chip detect and others are into the slot node. So we have to parse
child nodes. If not NULL, slot node will be used instead of the device
node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
Hi,
Since this patch is only a RFC, I have not yet updated drivers using this
function.
I would like to use mmc_of_parse to reduce code duplication. My issue is
that
atmel mci is a bit different from others mci host since it can provide
several slots, so it allocates several mmc hosts. By the way, it is not the
only one.
When calling mmc_alloc_host, host-parent is set to pdev-dev.
mmc_of_parse
uses host-parent-of_node but in my case settings are in the slot nodes
so in
the child nodes. That's why I would like to have a way to tell which node I
want to use.
Seems reasonable, thanks for working on this!
Regards
Ludovic
drivers/mmc/core/host.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index fdea825..ed6cea5 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
/**
* mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot: some devices provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
--
1.7.9.5
How about adding a new API, __mmc_of_parse((struct mmc_host *host,
struct device_node *slot)
Then let the old API mmc_of_parse() remain as is, but let it call the
new API with slot == NULL.
Atmel can then use the new API, but the other drivers can remain as is.
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 1/2] printk: Add context information to the header of /dev/kmsg
Hi, (2014/05/20 12:36), valdis.kletni...@vt.edu wrote: On Mon, 19 May 2014 19:28:38 +0900, Yoshihiro YUNOMAE said: The header information is changed as follows: prefix,seq#,timestamp,fragmented,PID/interrupt context;msg Has this been tested with popular userspace that reads /dev/kmsg, to make sure that it actually plays nice with a 5th field being added? Yes, I know I checked it for systemd-journald and rsyslog on the source code level, those tools don't handle new flag and field before ';' in the header of /dev/kmsg. Those tools use only log level, sequence#, and timestamp. So, even if we add these new flag and field for each message, those tools will be able to work. But, we'll fix this issue by other method if we found it in any subsystems except for the SCSI layer. (In the SCSI layer, we'll tackle this issue by using tracing feature.) Thank you, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 0/2] ftrace: Introduce the new I/F nr_saved_cmdlines
Hi Steven, Would you review this patch set? Thanks, Yoshihiro YUNOMAE (2014/02/20 17:44), Yoshihiro YUNOMAE wrote: Hi, This patch set introduces the new I/F nr_saved_cmdlines for increasing the number of saved cmdlines. Current saved_cmdlines can store just 128 command names and PIDs, but process names are often lost like ... when we read trace data. If the process exists, we can get the name by using ps command. However, if the process already has not existed, we cannot get the name. To solve this issue, we introduce the new I/F nr_saved_cmdlines to expand the max number of saved command line names. This I/F is very simple. If we write a number to nr_saved_cmdlines, the number of command name will be stored. And, if we read the I/F, we can get current maximum number of command name. The default number is 128 which is current default number, so this patch does not change the usage of memory for saved_cmdlines when we boot kernel. Thanks! Changes in V2: - Fix a racing problem of savedcmd between saved_cmdlines I/F and nr_saved_cmdlines I/F. If one reads saved_cmdlines and writes a value to nr_saved_cmdlines at the same time, then the write returns -EBUSY. [2/2] --- Yoshihiro YUNOMAE (2): ftrace: Make saved_cmdlines use seq_read ftrace: Introduce nr_saved_cmdlines I/F kernel/trace/trace.c | 316 +- 1 file changed, 261 insertions(+), 55 deletions(-) -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the devicetree tree
Dear Stephen Rothwell, On Mon, 26 May 2014 15:05:57 +1000, Stephen Rothwell wrote: diff --git a/drivers/of/base.c b/drivers/of/base.c index 395ee2b3146d..03e7fc6c93e8 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1901,10 +1901,6 @@ int of_update_property(struct device_node *np, struct property *newprop) if (!of_kset) return 0; - /* At early boot, bail out and defer setup to of_init() */ - if (!of_kset) - return found ? 0 : -ENODEV; - Seems like this is in fact reverting my change entirely, so maybe Grant should drop my patch instead? Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Javier,
On 05/23/2014 12:40 PM, Javier Martinez Canillas wrote:
Hello Roger,
On Fri, May 23, 2014 at 10:16 AM, Roger Quadros rog...@ti.com wrote:
Ezequiel Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
On 22 May 01:51 PM, Javier Martinez Canillas wrote:
On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
On 21 May 02:20 PM, Roger Quadros wrote:
For DT boot:
- The GPMC controller node should have a chip select (CS) node for each
used
chip select. The CS node must have a child device node for each device
attached to that chip select. Properties for that child are GPMC
agnostic.
i.e.
gpmc {
cs0 {
nand0 {
}
};
cs1 {
nor0 {
}
}
...
};
While I agree that the GPMC driver is a bit messy, I'm not sure it's
possible
to go through such a complete devicetree binding re-design (breaking
backwards
compatibility) now that the binding is already in production.
Why not? especially if the existing bindings are poorly dones. Is anyone
using these
bindings burning the DT into ROM and can't change it when they update the
kernel?
While I do agree that your DT bindings are much better than the
current ones, there is a policy that DT bindings are an external API
and once are released with a kernel are set in stone and can't be
changed.
Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
versions. Users can't be coherced into a DTB update after a kernel update.
That said, I don't really care if you break compatilibity in this case.
Rather, I'm suggesting that you make sure this change is going to be
accepted
upstream, before doing any more work. The DT maintainers are reluctant to do
so.
Appreciate your concern.
Would be really nice if you can review patches 1-12. They have nothing to do
with DT changes.
Thanks.
Overall your patches looks good to me. But I think it's better to wait
until Tony removes the legacy board files for OMAP2+ since AFAIU at
least the following patches could be dropped or trimmed down when
board files are gone:
[RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS
space and poplulate
[RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup
[RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use
generic_gpmc_init()
Patches 1-3 and 5 are independent and can be applied in the meantime
as a preparation for further changes following board files removal.
I really like patches 9-12 since those moves some NAND add-hoc code to
the NAND driver where it really belongs. I think that similar changes
can be made for OneNAND and push the special case handling code from
GPMC driver to drivers/mtd/onenand/omap2.c.
Other devices (nor, ethernet, uart, etc) are already using
gpmc_probe_generic_child() so I hope we can isolate the NAND and
OneNAND specific changes and just use a single probe function for all
child devices and possibly get even need the enum gpmc_omap_type you
are adding on your struct gpmc_omap_cs_data.
Yes, I was thinking the same.
So what do you think if as a first step we add the platform data as
you propose with all the commons timings and settings there, move all
the possible code to NAND and OneNAND drivers and try to use a single
configuration function for all child devices?
Yes, I agree.
Then once board files are gone we can do further cleanup in the driver
and then we can discuss about changing the DT bindings. Maybe we can
even change it while keeping backwards compatibility? Although I'm not
sure about the last point I think that at least is worth to discuss
it.
OK.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: rtl8192u: r819xU_firmware_img.c Fixed checkpatch.pl ERRORs
On Sun, May 25, 2014 at 09:15:06AM -0700, Chaitanya Hazarey wrote: Fixed a lot of errors of the type ERROR: space required after that ',' (ctx:VxV) Added tabs at the beginning of line. Signed-off-by: Chaitanya Hazarey c...@24.io --- Great. :) Thanks. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: divider: Fix table round up function
On 05/23/2014 11:39 PM, Mike Turquette wrote:
Quoting Maxime COQUELIN (2014-05-07 09:48:52)
Commit 1d9fe6b97 (clk: divider: Fix best div calculation for power-of-two and
table dividers) introduces a regression in its _table_round_up function.
When the divider passed to this function is greater than the max divider
available in the table, this function returns table's max divider.
Problem is that it causes an infinite loop in clk_divider_bestdiv() because
_next_div() will never return a value greater than maxdiv.
Instead of returning table's max divider, this patch returns INT_MAX.
Reported-by: Fabio Estevam feste...@gmail.com
Reported-by: Shawn Guo shawn@freescale.com
Tested-by: Fabio Estevam feste...@gmail.com
Cc: Mike Turquette mike.turque...@linaro.org
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Pulled into clk-fixes for -rc7.
Thanks Mike.
Regards,
Maxime
Regards,
Mike
---
drivers/clk/clk-divider.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index b3c8396..cf9114a 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -158,7 +158,7 @@ static bool _is_valid_div(struct clk_divider *divider,
unsigned int div)
static int _round_up_table(const struct clk_div_table *table, int div)
{
const struct clk_div_table *clkt;
- int up = _get_table_maxdiv(table);
+ int up = INT_MAX;
for (clkt = table; clkt-div; clkt++) {
if (clkt-div == div)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
On 05/23/2014 05:53 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140523 01:17]: On 05/22/2014 05:46 PM, Ezequiel Garcia wrote: On 22 May 01:51 PM, Javier Martinez Canillas wrote: On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote: On 21 May 02:20 PM, Roger Quadros wrote: While I agree that the GPMC driver is a bit messy, I'm not sure it's possible to go through such a complete devicetree binding re-design (breaking backwards compatibility) now that the binding is already in production. Why not? especially if the existing bindings are poorly dones. Is anyone using these bindings burning the DT into ROM and can't change it when they update the kernel? While I do agree that your DT bindings are much better than the current ones, there is a policy that DT bindings are an external API and once are released with a kernel are set in stone and can't be changed. Exactly. The DT binding is considered an ABI. Thus, invariant across kernel versions. Users can't be coherced into a DTB update after a kernel update. That said, I don't really care if you break compatilibity in this case. Rather, I'm suggesting that you make sure this change is going to be accepted upstream, before doing any more work. The DT maintainers are reluctant to do so. Appreciate your concern. Would be really nice if you can review patches 1-12. They have nothing to do with DT changes. Thanks. I'm mostly concerned about keeping things working. I think the only way we can keep things working is to keep support for the old binding around in addition to the new one. That way we can update devices one at a time. Good to hear that you are not keen on keeping the old bindings forever. I understand that we need to keep things working during the transition. I'll think of something to maintain backward compatibility while supporting the new binding. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the cgroup tree with Linus' tree
Hi Tejun,
Today's linux-next merge of the cgroup tree got a conflict in
mm/memcontrol.c between commit 6f6acb00514c (memcg: fix swapcache
charge from kernel thread context) from Linus' tree and commit
ec903c0c858e (cgroup: rename css_tryget*() to css_tryget_online*())
from the cgroup tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/memcontrol.c
index 5177c6d4a2dd,b6f91d61b3af..
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -1077,19 -1074,10 +1074,19 @@@ static struct mem_cgroup *get_mem_cgrou
rcu_read_lock();
do {
- memcg = mem_cgroup_from_task(rcu_dereference(mm-owner));
- if (unlikely(!memcg))
+ /*
+ * Page cache insertions can happen withou an
+ * actual mm context, e.g. during disk probing
+ * on boot, loopback IO, acct() writes etc.
+ */
+ if (unlikely(!mm))
memcg = root_mem_cgroup;
+ else {
+ memcg =
mem_cgroup_from_task(rcu_dereference(mm-owner));
+ if (unlikely(!memcg))
+ memcg = root_mem_cgroup;
+ }
- } while (!css_tryget(memcg-css));
+ } while (!css_tryget_online(memcg-css));
rcu_read_unlock();
return memcg;
}
signature.asc
Description: PGP signature
Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
On Mon, May 26, 2014 at 02:26:24PM +0800, Chao Yu wrote:
Hi changman,
-Original Message-
From: Changman Lee [mailto:cm224@samsung.com]
Sent: Friday, May 23, 2014 1:14 PM
To: Jaegeuk Kim
Cc: Chao Yu; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace
f2fs_submit_page_mbio event in
ra_sum_pages
On Wed, May 21, 2014 at 12:36:46PM +0900, Jaegeuk Kim wrote:
Hi Chao,
2014-05-16 (금), 17:14 +0800, Chao Yu:
Previously we allocate pages with no mapping in ra_sum_pages(), so we
may
encounter a crash in event trace of f2fs_submit_page_mbio where we
access
mapping data of the page.
We'd better allocate pages in bd_inode mapping and invalidate these
pages after
we restore data from pages. It could avoid crash in above scenario.
Call Trace:
[f1031630] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
[f10377bb] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
[f103c5da] restore_node_summary+0x13a/0x280 [f2fs]
[f103e22d] build_curseg+0x2bd/0x620 [f2fs]
[f104043b] build_segment_manager+0x1cb/0x920 [f2fs]
[f1032c85] f2fs_fill_super+0x535/0x8e0 [f2fs]
[c115b66a] mount_bdev+0x16a/0x1a0
[f102f63f] f2fs_mount+0x1f/0x30 [f2fs]
[c115c096] mount_fs+0x36/0x170
[c1173635] vfs_kern_mount+0x55/0xe0
[c1175388] do_mount+0x1e8/0x900
[c1175d72] SyS_mount+0x82/0xc0
[c16059cc] sysenter_do_call+0x12/0x22
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/node.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3d60d3d..b5cd814 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1658,13 +1658,16 @@ int recover_inode_page(struct f2fs_sb_info
*sbi, struct page *page)
/*
* ra_sum_pages() merge contiguous pages into one bio and submit.
- * these pre-readed pages are linked in pages list.
+ * these pre-readed pages are alloced in bd_inode's mapping tree.
*/
-static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head
*pages,
+static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
int start, int nrpages)
{
struct page *page;
+ struct inode *inode = sbi-sb-s_bdev-bd_inode;
How about use sbi-meta_inode instead of bd_inode, then we can do
caching summary pages for further i/o.
In my understanding, In ra_sum_pages() we readahead node pages in NODE
segment,
then we could padding current summary caching with nid of node page's footer.
So we should not cache this readaheaded pages in meta_inode's mapping.
Do I miss something?
Regards
Sorry, you're right. Forget about caching. I've confused ra_sum_pages with
summary segments.
+ struct address_space *mapping = inode-i_mapping;
int page_idx = start;
+ int alloced, readed;
struct f2fs_io_info fio = {
.type = META,
.rw = READ_SYNC | REQ_META | REQ_PRIO
@@ -1672,21 +1675,23 @@ static int ra_sum_pages(struct f2fs_sb_info
*sbi, struct list_head
*pages,
for (; page_idx start + nrpages; page_idx++) {
/* alloc temporal page for read node summary info*/
- page = alloc_page(GFP_F2FS_ZERO);
+ page = grab_cache_page(mapping, page_idx);
if (!page)
break;
-
- lock_page(page);
- page-index = page_idx;
- list_add_tail(page-lru, pages);
+ page_cache_release(page);
IMO, we don't need to do like this.
Instead,
for() {
page = grab_cache_page();
if (!page)
break;
page[page_idx] = page;
f2fs_submit_page_mbio(sbi, page, fio);
}
f2fs_submit_merged_bio(sbi, META, READ);
return page_idx - start;
Afterwards, in restore_node_summry(),
lock_page() will wait the end_io for read.
...
f2fs_put_page(pages[index], 1);
Thanks,
}
- list_for_each_entry(page, pages, lru)
- f2fs_submit_page_mbio(sbi, page, page-index, fio);
+ alloced = page_idx - start;
+ readed = find_get_pages_contig(mapping, start, alloced, pages);
+ BUG_ON(alloced != readed);
+
+ for (page_idx = 0; page_idx readed; page_idx++)
+ f2fs_submit_page_mbio(sbi, pages[page_idx],
+ pages[page_idx]-index, fio);
f2fs_submit_merged_bio(sbi, META, READ);
- return page_idx - start;
+ return readed;
}
[RESEND PATCH 0/5] charger/mfd: max14577: Part 2 of adding support for MAX77836
Dear Dmitry, David, This is resend of second part of patches adding support for MAX77836 device to the max14577 drivers. These patches are hanging on the lists for some time. Could you look at them and give me acks or any comment what have to be fixed? It is still before 3.16 merge window so your acks would be appreciated. If it is possible I would like to push the patches through Lee Jones' MFD tree (I already have other necessary acks). I need acks or reviews from power supply subsystem maintainers for patches: - 1/5: charger: max14577: Add support for MAX77836 charger - 3/5: charger: max14577: Configure battery-dependent settings from DTS - 4/5: power: max17040: Add ID for MAX77836 Fuel Gauge block These patches were published for the first time around February 2014. Could you look at them? Below is original cover letter. Best regards, Krzysztof Kozlowski Cover letter This is second part of patches adding support for MAX77836 device to the max14577 drivers. The first part [1] was applied by Lee Jones [2][3] and this patchset *depends* on it. This patchset changes the max14577 charger and regulator drivers and documents Device Tree bindings. The patches 1 to 3 depends on each other so they should be pulled at once. Patches 4, 5 and 6 can be applied independently. However still the smoothest way to apply this would be through one tree after obtaining necessary acks from maintainers. Changes since v4 (for this second part only) 1. Updated Kconfig entries mentioning MAX77836. 2. Added patch 5/6 (regulator: max14577: Implement SUSPEND mode for MAX77836 LDO-s) 3. Charger: Require a charger subnode in DTS with charger settings. Previously the charger driver didn't use any properties from DTS. Now it needs a subnode with settings because it supports different devices with different charging characteristics. 4. Rebased on 3.15-rc2. Changes since v3 1. Applied minor fixes (pointed by Lee Jones). 2. Added one ACK (Lee Jones) and Review-by (Tomasz Figa). 3. Patch 14/charger: Minor change in parsing EOC value from DTS. 4. Rebased on next-20140224. Changes since v2 1. Added ACK-s. 2. Applied minor checkpatch fixes (pointed by Lee Jones). 3. Rebased on next-20140217. Changes since v1 1. Added ACK-s, reviews and tested-by tags. 2. Removed applied patches (they were merged to the linux-next tree). 3. Applied comments from review (Lee Jones) to 5/15 (detection of device type) and 8/15 (add max77836 support to max14577). 4. Rebased on next tree. 5. Added patch 13 and 14 (pointed by Jenny Tc): - regulator/mfd: max14577: Export symbols for calculating charger current - charger: max14577: Configure battery-dependent settings from DTS 6. Updated bindings documentation with new charger bindings. References == [1] http://thread.gmane.org/gmane.linux.kernel/1682503 [2] http://www.spinics.net/lists/kernel/msg1728274.html [3] https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/log/?h=ib-mfd-extcon-3.16 Previous, full v4 patchset can be found here: http://thread.gmane.org/gmane.linux.kernel/1654267 Krzysztof Kozlowski (5): charger: max14577: Add support for MAX77836 charger regulator/mfd: max14577: Export symbols for calculating charger current charger: max14577: Configure battery-dependent settings from DTS power: max17040: Add ID for MAX77836 Fuel Gauge block devicetree: mfd: max14577: Add device tree bindings document Documentation/devicetree/bindings/mfd/max14577.txt | 152 +++ drivers/mfd/max14577.c | 100 ++- drivers/power/Kconfig | 4 +- drivers/power/max14577_charger.c | 291 ++--- drivers/power/max17040_battery.c | 1 + drivers/regulator/max14577.c | 80 +- include/linux/mfd/max14577-private.h | 92 +-- include/linux/mfd/max14577.h | 31 +++ 8 files changed, 614 insertions(+), 137 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 4/5] power: max17040: Add ID for MAX77836 Fuel Gauge block
MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
can be safely re-used. The patch adds MAX77836 ID to array of
i2c_device_id.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Anton Vorontsov an...@enomsg.org
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/power/max17040_battery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/max17040_battery.c b/drivers/power/max17040_battery.c
index 0fbac861080d..165ffe381803 100644
--- a/drivers/power/max17040_battery.c
+++ b/drivers/power/max17040_battery.c
@@ -278,6 +278,7 @@ static SIMPLE_DEV_PM_OPS(max17040_pm_ops, max17040_suspend,
max17040_resume);
static const struct i2c_device_id max17040_id[] = {
{ max17040, 0 },
+ { max77836-battery, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, max17040_id);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/5] charger: max14577: Add support for MAX77836 charger
Add support for MAX77836 charger to the max14577 driver. The MAX77836
charger is almost the same as 14577 model except:
- No dead-battery detection;
- Support for special charger (like in MAX77693);
- Support for DX over-voltage protection (like in MAX77693);
- Lower values of charging current (two times lower current for
slow/fast charge, much lower EOC current);
- Slightly different values in ChgTyp field of STATUS2 register. On
MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
0x6 means special charger and 0x7 is reserved. Regardless of these
differences the driver maps them to one enum max14577_muic_charger_type.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Anton Vorontsov an...@enomsg.org
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/power/Kconfig| 4 +-
drivers/power/max14577_charger.c | 77 +---
include/linux/mfd/max14577-private.h | 54 ++---
3 files changed, 104 insertions(+), 31 deletions(-)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ba6975123071..94086a5238c6 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -318,11 +318,11 @@ config CHARGER_MANAGER
with help of suspend_again support.
config CHARGER_MAX14577
- tristate Maxim MAX14577 MUIC battery charger driver
+ tristate Maxim MAX14577/77836 battery charger driver
depends on MFD_MAX14577
help
Say Y to enable support for the battery charger control sysfs and
- platform data of MAX14577 MUICs.
+ platform data of MAX14577/77836 MUICs.
config CHARGER_MAX8997
tristate Maxim MAX8997/MAX8966 PMIC battery charger driver
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index fad2a75b3604..19c8f42abf24 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -1,7 +1,7 @@
/*
- * Battery charger driver for the Maxim 14577
+ * max14577_charger.c - Battery charger driver for the Maxim 14577/77836
*
- * Copyright (C) 2013 Samsung Electronics
+ * Copyright (C) 2013,2014 Samsung Electronics
* Krzysztof Kozlowski k.kozlow...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -25,10 +25,35 @@ struct max14577_charger {
struct max14577 *max14577;
struct power_supply charger;
- unsigned intcharging_state;
- unsigned intbattery_state;
+ unsigned intcharging_state;
+ unsigned intbattery_state;
};
+/*
+ * Helper function for mapping values of STATUS2/CHGTYP register on max14577
+ * and max77836 chipsets to enum maxim_muic_charger_type.
+ */
+static enum max14577_muic_charger_type maxim_get_charger_type(
+ enum maxim_device_type dev_type, u8 val) {
+ switch (val) {
+ case MAX14577_CHARGER_TYPE_NONE:
+ case MAX14577_CHARGER_TYPE_USB:
+ case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
+ case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
+ case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
+ case MAX14577_CHARGER_TYPE_SPECIAL_1A:
+ return val;
+ case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+ case MAX14577_CHARGER_TYPE_RESERVED:
+ if (dev_type == MAXIM_DEVICE_TYPE_MAX77836)
+ val |= 0x8;
+ return val;
+ default:
+ WARN_ONCE(1, max14577: Unsupported chgtyp register value
0x%02x, val);
+ return val;
+ }
+}
+
static int max14577_get_charger_state(struct max14577_charger *chg)
{
struct regmap *rmap = chg-max14577-regmap;
@@ -89,19 +114,23 @@ static int max14577_get_online(struct max14577_charger
*chg)
{
struct regmap *rmap = chg-max14577-regmap;
u8 reg_data;
+ enum max14577_muic_charger_type chg_type;
max14577_read_reg(rmap, MAX14577_MUIC_REG_STATUS2, reg_data);
reg_data = ((reg_data STATUS2_CHGTYP_MASK) STATUS2_CHGTYP_SHIFT);
- switch (reg_data) {
+ chg_type = maxim_get_charger_type(chg-max14577-dev_type, reg_data);
+ switch (chg_type) {
case MAX14577_CHARGER_TYPE_USB:
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+ case MAX77836_CHARGER_TYPE_SPECIAL_BIAS:
return 1;
case MAX14577_CHARGER_TYPE_NONE:
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
case MAX14577_CHARGER_TYPE_RESERVED:
+ case MAX77836_CHARGER_TYPE_RESERVED:
default:
return 0;
}
@@ -118,10 +147,12 @@ static int max14577_get_battery_health(struct
max14577_charger *chg)
struct regmap *rmap =
Re: [PATCH RFC] mmc: add slot argument to mmc_of_parse
On Mon, May 26, 2014 at 09:03:01AM +0200, Ludovic Desroches wrote:
Hi,
Sorry I was on vacation, I'll send a cleaner patch updating other drivers
this week.
Continuing to clear out my inbox, I have seen you send a patch for it.
Thanks.
Regards
Ludovic
On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
Hi, All.
This patch is working on progress?
I want to merge this patch for fixing dw-mmc controller problem.
If this patch didn't work on progress, i will send the patch based-on this
patch.
Best Regards,
Jaehoon Chung
On 05/14/2014 06:53 PM, Ulf Hansson wrote:
On 7 May 2014 12:06, Ludovic Desroches ludovic.desroc...@atmel.com
wrote:
Some hosts manage several slots. In these case information such as the
bus
width, chip detect and others are into the slot node. So we have to parse
child nodes. If not NULL, slot node will be used instead of the device
node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
Hi,
Since this patch is only a RFC, I have not yet updated drivers using this
function.
I would like to use mmc_of_parse to reduce code duplication. My issue is
that
atmel mci is a bit different from others mci host since it can provide
several slots, so it allocates several mmc hosts. By the way, it is not
the
only one.
When calling mmc_alloc_host, host-parent is set to pdev-dev.
mmc_of_parse
uses host-parent-of_node but in my case settings are in the slot nodes
so in
the child nodes. That's why I would like to have a way to tell which
node I
want to use.
Seems reasonable, thanks for working on this!
Regards
Ludovic
drivers/mmc/core/host.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index fdea825..ed6cea5 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
/**
* mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot: some devices provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
--
1.7.9.5
How about adding a new API, __mmc_of_parse((struct mmc_host *host,
struct device_node *slot)
Then let the old API mmc_of_parse() remain as is, but let it call the
new API with slot == NULL.
Atmel can then use the new API, but the other drivers can remain as is.
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 3/5] charger: max14577: Configure battery-dependent settings from DTS
Remove hard-coded values for:
- Fast Charge current,
- End Of Charge current,
- Fast Charge timer,
- Overvoltage Protection Threshold,
- Battery Constant Voltage,
and use DTS to configure them. This allows using the max14577 charger
driver with different batteries.
Now the charger driver requires valid configuration data from DTS. In
case of wrong configuration data it fails during probe. Patch adds
of_compatible to the charger mfd cell in MFD driver core.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Jenny Tc jenny...@intel.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/max14577.c | 5 +-
drivers/power/max14577_charger.c | 232 +++
include/linux/mfd/max14577-private.h | 16 +++
include/linux/mfd/max14577.h | 8 ++
4 files changed, 233 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index cef2149ac096..13030573a8ca 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -116,7 +116,10 @@ static struct mfd_cell max14577_devs[] = {
.name = max14577-regulator,
.of_compatible = maxim,max14577-regulator,
},
- { .name = max14577-charger, },
+ {
+ .name = max14577-charger,
+ .of_compatible = maxim,max14577-charger,
+ },
};
static struct mfd_cell max77836_devs[] = {
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index 19c8f42abf24..f32f94a9a144 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -19,6 +19,7 @@
#include linux/platform_device.h
#include linux/power_supply.h
#include linux/mfd/max14577-private.h
+#include linux/mfd/max14577.h
struct max14577_charger {
struct device *dev;
@@ -27,6 +28,8 @@ struct max14577_charger {
unsigned intcharging_state;
unsigned intbattery_state;
+
+ struct max14577_charger_platform_data *pdata;
};
/*
@@ -178,15 +181,107 @@ static int max14577_get_present(struct max14577_charger
*chg)
return 1;
}
+static inline int max14577_init_constant_voltage(struct max14577_charger *chg,
+ unsigned int uvolt)
+{
+ u8 reg_data;
+
+ if (uvolt MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN ||
+ uvolt MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+ return -EINVAL;
+
+ if (uvolt == 420)
+ reg_data = 0x0;
+ else if (uvolt == MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+ reg_data = 0x1f;
+ else if (uvolt = 428) {
+ unsigned int val = uvolt;
+
+ val -= MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN;
+ val /= MAXIM_CHARGER_CONSTANT_VOLTAGE_STEP;
+ if (uvolt = 418)
+ reg_data = 0x1 + val;
+ else
+ reg_data = val; /* Fix for gap between 4.18V and 4.22V
*/
+ } else
+ return -EINVAL;
+
+ reg_data = CHGCTRL3_MBCCVWRC_SHIFT;
+
+ return max14577_write_reg(chg-max14577-regmap,
+ MAX14577_CHG_REG_CHG_CTRL3, reg_data);
+}
+
+static inline int max14577_init_eoc(struct max14577_charger *chg,
+ unsigned int uamp)
+{
+ unsigned int current_bits = 0xf;
+ u8 reg_data;
+
+ switch (chg-max14577-dev_type) {
+ case MAXIM_DEVICE_TYPE_MAX77836:
+ if (uamp 5000)
+ return -EINVAL; /* Requested current is too low */
+
+ if (uamp = 7500 uamp 1)
+ current_bits = 0x0;
+ else if (uamp = 5) {
+ /* 5000, 7499 and 1, 5 */
+ current_bits = uamp / 5000;
+ } else {
+ uamp = min(uamp, 10U) - 5U;
+ current_bits = 0xa + uamp / 1;
+ }
+ break;
+
+ case MAXIM_DEVICE_TYPE_MAX14577:
+ default:
+ if (uamp MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN)
+ return -EINVAL; /* Requested current is too low */
+
+ uamp = min(uamp, MAX14577_CHARGER_EOC_CURRENT_LIMIT_MAX);
+ uamp -= MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN;
+ current_bits = uamp / MAX14577_CHARGER_EOC_CURRENT_LIMIT_STEP;
+ break;
+ }
+
+ reg_data = current_bits CHGCTRL5_EOCS_SHIFT;
+
+ return max14577_update_reg(chg-max14577-regmap,
+ MAX14577_CHG_REG_CHG_CTRL5, CHGCTRL5_EOCS_MASK,
+ reg_data);
+}
+
+static inline int max14577_init_fast_charge(struct max14577_charger *chg,
+ unsigned int uamp)
+{
+ u8 reg_data;
+ int ret;
+ const struct
Re: [PATCH v2 01/11] sched: fix imbalance flag reset
On 25 May 2014 12:33, Preeti U Murthy pre...@linux.vnet.ibm.com wrote: Hi Vincent, On 05/23/2014 09:22 PM, Vincent Guittot wrote: The imbalance flag can stay set whereas there is no imbalance. Let assume that we have 3 tasks that run on a dual cores /dual cluster system. We will have some idle load balance which are triggered during tick. Unfortunately, the tick is also used to queue background work so we can reach the situation where short work has been queued on a CPU which already runs a task. The load balance will detect this imbalance (2 tasks on 1 CPU and an idle CPU) and will try to pull the waiting task on the idle CPU. The waiting task is a worker thread that is pinned on a CPU so an imbalance due to pinned task is detected and the imbalance flag is set. Then, we will not be able to clear the flag because we have at most 1 task on each CPU but the imbalance flag will trig to useless active load balance between the idle CPU and the busy CPU. Why do we do active balancing today when there is at-most 1 task on the busiest cpu? Shouldn't we be skipping load balancing altogether? If we do active balancing when the number of tasks = 1, it will lead to a ping pong right? That's the purpose of the patch to prevent this useless active load balance. When the imbalance flag is set, an active load balance is triggered whatever the load balance is because of pinned tasks that prevents a balance state. Vincent Regards Preeti U Murthy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the clockevents tree with the arm-soc tree
Hi Daniel, On Mon, May 26, 2014 at 03:43:31PM +1000, Stephen Rothwell wrote: Hi Daniel, Today's linux-next merge of the clockevents tree got a conflict in arch/arm/boot/dts/vf610.dtsi between commit 0517fe6aa880 (ARM: dts: vf610-twr: Add support for sdhc1) from the arm-soc tree and commit 07513e1330a9 (ARM: dts: vf610: Add Freescale FlexTimer Module timer node) from the clockevents tree. Next time, please leave the dts patches to go via arch tree, so that we can save such conflicts. Shawn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 2/5] regulator/mfd: max14577: Export symbols for calculating charger current
This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.
The patch moves from regulator driver to MFD core driver and exports:
- function for calculating register value for charger's current;
- table of limits for chargers (MAX14577, MAX77836).
Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Mark Brown broo...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/max14577.c | 95
drivers/regulator/max14577.c | 80 ++
include/linux/mfd/max14577-private.h | 22 -
include/linux/mfd/max14577.h | 23 +
4 files changed, 133 insertions(+), 87 deletions(-)
diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index 484d372a4892..cef2149ac096 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -26,6 +26,87 @@
#include linux/mfd/max14577.h
#include linux/mfd/max14577-private.h
+/*
+ * Table of valid charger currents for different Maxim chipsets.
+ * It is placed here because it is used by both charger and regulator driver.
+ */
+const struct maxim_charger_current maxim_charger_currents[] = {
+ [MAXIM_DEVICE_TYPE_UNKNOWN] = { 0, 0, 0, 0 },
+ [MAXIM_DEVICE_TYPE_MAX14577] = {
+ .min= MAX14577_CHARGER_CURRENT_LIMIT_MIN,
+ .high_start = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_START,
+ .high_step = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+ .max= MAX14577_CHARGER_CURRENT_LIMIT_MAX,
+ },
+ [MAXIM_DEVICE_TYPE_MAX77836] = {
+ .min= MAX77836_CHARGER_CURRENT_LIMIT_MIN,
+ .high_start = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_START,
+ .high_step = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+ .max= MAX77836_CHARGER_CURRENT_LIMIT_MAX,
+ },
+};
+EXPORT_SYMBOL_GPL(maxim_charger_currents);
+
+/*
+ * maxim_charger_calc_reg_current - Calculate register value for current
+ * @limits:constraints for charger, matching the MBCICHWRC register
+ * @min_ua:minimal requested current, micro Amps
+ * @max_ua:maximum requested current, micro Amps
+ * @dst: destination to store calculated register value
+ *
+ * Calculates the value of MBCICHWRC (Fast Battery Charge Current) register
+ * for given current and stores it under pointed 'dst'. The stored value
+ * combines low bit (MBCICHWRCL) and high bits (MBCICHWRCH). It is also
+ * properly shifted.
+ *
+ * The calculated register value matches the current which:
+ * - is always between limits.min, limits.max;
+ * - is always less or equal to max_ua;
+ * - is the highest possible value;
+ * - may be lower than min_ua.
+ *
+ * On success returns 0. On error returns -EINVAL (requested min/max current
+ * is outside of given charger limits) and 'dst' is not set.
+ */
+int maxim_charger_calc_reg_current(const struct maxim_charger_current *limits,
+ unsigned int min_ua, unsigned int max_ua, u8 *dst)
+{
+ unsigned int current_bits = 0xf;
+
+ if (min_ua max_ua)
+ return -EINVAL;
+
+ if (min_ua limits-max || max_ua limits-min)
+ return -EINVAL;
+
+ if (max_ua limits-high_start) {
+ /*
+* Less than high_start, so set the minimal current
+* (turn Low Bit off, 0 as high bits).
+*/
+ *dst = 0x0;
+ return 0;
+ }
+
+ /* max_ua is in range: high_start, infinite, cut it to limits.max */
+ max_ua = min(limits-max, max_ua);
+ max_ua -= limits-high_start;
+ /*
+* There is no risk of overflow 'max_ua' here because:
+* - max_ua = limits.high_start
+* - BUILD_BUG checks that 'limits' are: max = high_start + high_step
+*/
+ current_bits = max_ua / limits-high_step;
+
+ /* Turn Low Bit on (use range limits.high_start, limits.max) ... */
+ *dst = 0x1 CHGCTRL4_MBCICHWRCL_SHIFT;
+ /* and set proper High Bits */
+ *dst |= current_bits CHGCTRL4_MBCICHWRCH_SHIFT;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(maxim_charger_calc_reg_current);
+
static struct mfd_cell max14577_devs[] = {
{
.name = max14577-muic,
@@ -465,6 +546,20 @@ static int __init max14577_i2c_init(void)
BUILD_BUG_ON(ARRAY_SIZE(max14577_i2c_id) != MAXIM_DEVICE_TYPE_NUM);
BUILD_BUG_ON(ARRAY_SIZE(max14577_dt_match) != MAXIM_DEVICE_TYPE_NUM);
+ /* Valid charger current values must be provided for each chipset */
+ BUILD_BUG_ON(ARRAY_SIZE(maxim_charger_currents) !=
MAXIM_DEVICE_TYPE_NUM);
[RESEND PATCH 5/5] devicetree: mfd: max14577: Add device tree bindings document
Add document describing device tree bindings for MAX14577 MFD
drivers: MFD core, extcon, regulator and charger.
Both MAX14577 and MAX77836 chipsets are documented.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Documentation/devicetree/bindings/mfd/max14577.txt | 152 +
1 file changed, 152 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt
diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt
b/Documentation/devicetree/bindings/mfd/max14577.txt
new file mode 100644
index ..b235250a7b41
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max14577.txt
@@ -0,0 +1,152 @@
+Maxim MAX14577/77836 Multi-Function Device
+
+MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+
+Battery Charger and SFOUT LDO output for powering USB devices. It is
+interfaced to host controller using I2C.
+
+MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge.
+
+
+Required properties:
+- compatible : Must be maxim,max14577 or maxim,max77836.
+- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836)
+- interrupts : IRQ line for the chip.
+- interrupt-parent : The parent interrupt controller.
+
+
+Required nodes:
+ - charger :
+ Node for configuring the charger driver.
+ Required properties:
+ - compatible : maxim,max14577-charger
+ or maxim,max77836-charger
+ - maxim,fast-charge-timer : Timer in hours to trigger the
+ INT3/MBCCHGERR interrupt; Valid values:
+ - 5, 6 or 7 (hours),
+ - 0 to disable.
+ - maxim,fast-charge-uamp : Current in uA for Fast Charge;
+ Valid values:
+ - for max14577: 9 - 95;
+ - for max77836: 45000 - 475000;
+ - maxim,eoc-uamp : Current in uA for End-Of-Charge mode;
+ Valid values:
+ - for max14577: 5 - 20;
+ - for max77836: 5000 - 10;
+ - maxim,ovp-uvolt : OverVoltage Protection Threshold in uV;
+ In an overvoltage condition, INT asserts and charging
+ stops. Valid values:
+ - 600, 650, 700, 750;
+ - maxim,constant-uvolt : Battery Constant Voltage in uV;
+ Valid values:
+ - 400 - 428 (step by 2);
+ - 435;
+
+
+Optional nodes:
+- max14577-muic/max77836-muic :
+ Node used only by extcon consumers.
+ Required properties:
+ - compatible : maxim,max14577-muic or maxim,max77836-muic
+
+- regulators :
+ Required properties:
+ - compatible : maxim,max14577-regulator
+ or maxim,max77836-regulator
+
+ May contain a sub-node per regulator from the list below. Each
+ sub-node should contain the constraints and initialization information
+ for that regulator. See regulator.txt for a description of standard
+ properties for these sub-nodes.
+
+ List of valid regulator names:
+ - for max14577: CHARGER, SAFEOUT.
+ - for max77836: CHARGER, SAFEOUT, LDO1, LDO2.
+
+ The SAFEOUT is a fixed voltage regulator so there is no need to specify
+ voltages for it.
+
+
+Example:
+
+#include dt-bindings/interrupt-controller/irq.h
+
+max14577@25 {
+ compatible = maxim,max14577;
+ reg = 0x25;
+ interrupt-parent = gpx1;
+ interrupts = 5 IRQ_TYPE_NONE;
+
+ muic: max14577-muic {
+ compatible = maxim,max14577-muic;
+ };
+
+ regulators {
+ compatible = maxim,max14577-regulator;
+
+ SAFEOUT {
+ regulator-name = SAFEOUT;
+ };
+ CHARGER {
+ regulator-name = CHARGER;
+ regulator-min-microamp = 9;
+ regulator-max-microamp = 95;
+ regulator-boot-on;
+ };
+ };
+
+ charger {
+ compatible = maxim,max14577-charger;
+
+ maxim,fast-charge-timer = 6;
+ maxim,constant-uvolt = 435;
+ maxim,fast-charge-uamp = 45;
+ maxim,eoc-uamp = 5;
+ maxim,ovp-uvolt = 650;
+ };
+};
+
+
+max77836@25 {
+ compatible = maxim,max77836;
+ reg = 0x25;
+ interrupt-parent = gpx1;
+ interrupts =
Re: [PATCH v2] zram: remove global tb_lock with fine grain lock
Hello,
Sorry for my late reply, because of a biz trip.
On Wed, May 21, 2014 at 3:51 PM, Minchan Kim minc...@kernel.org wrote:
Hello Andrew,
On Tue, May 20, 2014 at 03:10:51PM -0700, Andrew Morton wrote:
On Thu, 15 May 2014 16:00:47 +0800 Weijie Yang weijie.y...@samsung.com
wrote:
Currently, we use a rwlock tb_lock to protect concurrent access to
the whole zram meta table. However, according to the actual access model,
there is only a small chance for upper user to access the same
table[index],
so the current lock granularity is too big.
The idea of optimization is to change the lock granularity from whole
meta table to per table entry (table - table[index]), so that we can
protect concurrent access to the same table[index], meanwhile allow
the maximum concurrency.
With this in mind, several kinds of locks which could be used as a
per-entry lock were tested and compared:
...
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -179,23 +179,32 @@ static ssize_t comp_algorithm_store(struct device
*dev,
return len;
}
-/* flag operations needs meta-tb_lock */
-static int zram_test_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static int zram_test_zero(struct zram_meta *meta, u32 index)
{
- return meta-table[index].flags BIT(flag);
+ return meta-table[index].value BIT(ZRAM_ZERO);
}
-static void zram_set_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static void zram_set_zero(struct zram_meta *meta, u32 index)
{
- meta-table[index].flags |= BIT(flag);
+ meta-table[index].value |= BIT(ZRAM_ZERO);
}
-static void zram_clear_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static void zram_clear_zero(struct zram_meta *meta, u32 index)
{
- meta-table[index].flags = ~BIT(flag);
+ meta-table[index].value = ~BIT(ZRAM_ZERO);
+}
+
+static int zram_get_obj_size(struct zram_meta *meta, u32 index)
+{
+ return meta-table[index].value (BIT(ZRAM_FLAG_SHIFT) - 1);
+}
+
+static void zram_set_obj_size(struct zram_meta *meta,
+ u32 index, int size)
+{
+ meta-table[index].value = (unsigned long)size |
+ ((meta-table[index].value ZRAM_FLAG_SHIFT)
+ZRAM_FLAG_SHIFT );
}
Let's sort out the types here? It makes no sense for `size' to be
signed. And I don't think we need *any* 64-bit quantities here
(discussed below).
So I think we can make `size' a u32 and remove that typecast.
Also, please use checkpatch ;)
I will remove the typecast and do checkpatch in the next patch version.
static inline int is_partial_io(struct bio_vec *bvec)
@@ -255,7 +264,6 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
goto free_table;
}
- rwlock_init(meta-tb_lock);
return meta;
free_table:
@@ -304,19 +312,19 @@ static void handle_zero_page(struct bio_vec *bvec)
flush_dcache_page(page);
}
-/* NOTE: caller should hold meta-tb_lock with write-side */
Can we please update this important comment rather than simply deleting
it?
Of couse, I will update it.
static void zram_free_page(struct zram *zram, size_t index)
{
struct zram_meta *meta = zram-meta;
unsigned long handle = meta-table[index].handle;
+ int size;
if (unlikely(!handle)) {
/*
* No memory is allocated for zero filled pages.
* Simply clear zero page flag.
*/
- if (zram_test_flag(meta, index, ZRAM_ZERO)) {
- zram_clear_flag(meta, index, ZRAM_ZERO);
+ if (zram_test_zero(meta, index)) {
+ zram_clear_zero(meta, index);
atomic64_dec(zram-stats.zero_pages);
}
return;
...
@@ -64,9 +76,8 @@ enum zram_pageflags {
/* Allocated for each disk page */
struct table {
unsigned long handle;
- u16 size; /* object size (excluding header) */
- u8 flags;
-} __aligned(4);
+ unsigned long value;
+};
Does `value' need to be 64 bit on 64-bit machines? I think u32 will be
sufficient? The struct will still be 16 bytes but if we then play
around adding __packed to this structure we should be able to shrink it
to 12 bytes, save large amounts of memory?
I agree that u32 is sufficient to value(size and flags), the reason I choice
unsigned long is as you said bit_spin_lock() requires a ulong *.
And does `handle' need to be 64-bit on 64-bit?
To me, it's a buggy. We should not have used (unsigned long) as zsmalloc's
handle from the beginning. Sometime it might be bigger than sizeof(unsigned
long)
because zsmalloc's handle consists of (pfn, obj idx) so pfn itself is already
unsigned long but more practically, if we consider MAX_PHYSMEM_BITS of
Re: balance storm
On Mon, 2014-05-26 at 11:04 +0800, Libo Chen wrote:
hi,
my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
3.4.24stable, startup 50 same process, every process is sample:
#include unistd.h
int main()
{
for (;;)
{
unsigned int i = 0;
while (i 100){
i++;
}
usleep(100);
}
return 0;
}
the result is process uses 15% cpu time, perf tool shows 70w migrations in 5
second.
My 8 socket 64 core DL980 running 256 copies (3.14-rt5) munches ~4%/copy
per top, and does roughly 1 sh*tload migrations, nano-work loop or not.
Turn SD_SHARE_PKG_RESOURCES off at MC (not a noop here), and consumption
drops to ~2%/copy, and migrations ('course) mostly go away.
vogelweide:/abuild/mike/:[0]# perf stat -a -e sched:sched_migrate_task -- sleep
5
Performance counter stats for 'system wide':
3108 sched:sched_migrate_task
5.001367910 seconds time elapsed
(turns SD_SHARE_PKG_RESOURCES back on)
vogelweide:/abuild/mike/:[0]# perf stat -a -e sched:sched_migrate_task -- sleep
5
Performance counter stats for 'system wide':
4182334 sched:sched_migrate_task
5.001365023 seconds time elapsed
vogelweide:/abuild/mike/:[0]#
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Neaten clk_summary output
Hi Mike,
On Fri, May 23, 2014 at 11:12 PM, Mike Turquette mturque...@linaro.org wrote:
Quoting Geert Uytterhoeven (2014-05-23 00:14:41)
On Tue, May 13, 2014 at 2:17 AM, Mike Turquette mturque...@linaro.org
wrote:
Quoting Geert Uytterhoeven (2014-03-25 04:16:24)
From: Geert Uytterhoeven geert+rene...@glider.be
- Limit ruler to 80 characters (was: 81),
- Widen rate column by 1 for nicer spacing,
- Right-align numbers and their column headers,
- Move a newline to reduce the number of seq_printf() calls,
- Use set_puts() for fixed strings.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Thanks for the fix. Taken into clk-next.
I don't see it in clk-next, though?
When I say clk-next I really mean my local/private branch. You'll see
it at the end of today when I push my next set of tested patches out to
my linaro mirror.
Thanks, I can see it now.
Sorry for being so impatient.
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the target-updates tree with the scsi tree
Hi Nicholas,
Today's linux-next merge of the target-updates tree got a conflict in
drivers/scsi/qla2xxx/qla_target.c between commit f83adb617f55
(qla2xxx: T10-Dif: add T10-PI support) from the scsi tree and commit
ed6849ff4921 (qla2xxx: Convert to percpu_ida session tag
pre-allocation) from the target-updates tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/scsi/qla2xxx/qla_target.c
index b1d10f9935c7,bd9c725c08e1..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -2705,15 -2164,18 +2704,22 @@@ done
void qlt_free_cmd(struct qla_tgt_cmd *cmd)
{
+ struct qla_tgt_sess *sess = cmd-sess;
+
- BUG_ON(cmd-sg_mapped);
+ ql_dbg(ql_dbg_tgt, cmd-vha, 0xe074,
+ %s: se_cmd[%p] ox_id %04x\n,
+ __func__, cmd-se_cmd,
+ be16_to_cpu(cmd-atio.u.isp24.fcp_hdr.ox_id));
+ BUG_ON(cmd-sg_mapped);
if (unlikely(cmd-free_sg))
kfree(cmd-sg);
- kmem_cache_free(qla_tgt_cmd_cachep, cmd);
+
+ if (!sess || !sess-se_sess) {
+ WARN_ON(1);
+ return;
+ }
+ percpu_ida_free(sess-se_sess-sess_tag_pool, cmd-se_cmd.map_tag);
}
EXPORT_SYMBOL(qlt_free_cmd);
@@@ -3149,12 -2533,11 +3119,12 @@@ static void __qlt_do_work(struct qla_tg
atio-u.isp24.fcp_cmnd.add_cdb_len]));
ql_dbg(ql_dbg_tgt, vha, 0xe022,
- qla_target: START qla command: %p lun: 0x%04x (tag %d)\n,
- cmd, cmd-unpacked_lun, cmd-tag);
+ qla_target: START qla cmd: %p se_cmd %p lun: 0x%04x (tag %d)
len(%d) ox_id %x\n,
+ cmd, cmd-se_cmd, cmd-unpacked_lun, cmd-tag, data_length,
+ cmd-atio.u.isp24.fcp_hdr.ox_id);
- ret = vha-hw-tgt.tgt_ops-handle_cmd(vha, cmd, cdb, data_length,
- fcp_task_attr, data_dir, bidi);
+ ret = ha-tgt.tgt_ops-handle_cmd(vha, cmd, cdb, data_length,
+ fcp_task_attr, data_dir, bidi);
if (ret != 0)
goto out_term;
/*
signature.asc
Description: PGP signature
Re: [RFT PATCH] regulator: s2mpa01: Use correct register for buck[36] ramp delay
Hi Krzysztof Apologies for the delay. I was on vacation during the early part of this month and got busy with some other stuff later and this mail fell through the cracks. On 23 May 2014 19:49, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi Sachin, The s2mpa01 regulator driver uses wrong registers for ramp delay (buck1 and buck3 in RAMP1, buck6 in RAMP2) but I am not sure which layout is proper (it seems that that buck1 should be in RAMP2 register). Could you check in S2MPA01 datasheet the registers for ramp delay for buck1, buck3 and buck6? I checked the datasheet available with me and according to it buck 1 and 6 share the ramp register 0x11 (RAMP2) (bit 4 and 5) and buck 3 uses bit 4 and 5 of register 0x10 (RAMP1). -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mmc: host: add slot argument to mmc_of_parse
On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Some hosts manage several slots. In these case information such as the
bus width, chi detect and others are into the slot node. So we have to
/s/chi detect/chip detect
parse child node. If not NULL, slot node will be used instead of the
device node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
drivers/mmc/core/host.c | 13 +
include/linux/mmc/host.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 95cceae..0f677b3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
#endif
/**
- * mmc_of_parse() - parse host's device-tree node
+ * __mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot : some device provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
@@ -459,7 +464,7 @@ out:
return ret;
}
-EXPORT_SYMBOL(mmc_of_parse);
+EXPORT_SYMBOL(__mmc_of_parse);
/**
* mmc_alloc_host - initialise the per-host structure.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424..c62af91 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-int mmc_of_parse(struct mmc_host *host);
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
+/*
+ * mmc_of_parse - parse host's device-tree node
+ * @host: host whose node should be parsed.
+ */
+static inline int mmc_of_parse(struct mmc_host *host)
+{
+ return __mmc_of_parse(host, NULL);
+}
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH RESEND] scsi: Output error messages using structured printk in single line
Hi Hannes,
(2014/05/21 15:30), Hannes Reinecke wrote:
On 05/21/2014 05:18 AM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of James Bottomley
Sent: Tuesday, May 20, 2014 9:22 PM
To: Yoshihiro YUNOMAE
Cc: Hannes Reinecke; Prarit Bhargava; linux-s...@vger.kernel.org; Kay
Sievers; linux-kernel@vger.kernel.org; Hidehiro Kawai; yrl.pp-
manager...@hitachi.com; Masami Hiramatsu
Subject: Re: [PATCH RESEND] scsi: Output error messages using structured
printk in single line
On Thu, 2014-02-27 at 13:17 +0900, Yoshihiro YUNOMAE wrote:
+/* Maximum size of a local buffer for structured printk */
+#define SCSI_LOG_LINE_MAX 512
+
+/* Local buffer for structured printk */
+struct scsi_log_line {
+int offset;
+char buf[SCSI_LOG_LINE_MAX];
+};
This piece isn't going to fly; it's an on stack allocation of 0.5kb;
that's too much for small stack kernels. Just changing this to a kalloc
is going be problematic too because we're in the io paths and the
allocation may fail. So I appreciate the problem, but I don't think the
solution works. Could we just tag the messages and use grep to put them
back together?
James
When the system gets busy, I've seen CDB bytes strung out with each
byte getting its own timestamp, with messages from different devices
and threads interleaved together, so like the idea of printing each
line with a single printk() call.
Most lines aren't anywhere near 512 bytes long. Can this be coded to
let the calling function define an appropriate buffer size for
whatever it is printing, with sizeof() used to bounds check?
As mentioned several times, I'm working on a patchset to update
scsi logging.
The original patchset tried to convert any logging message into a single
statement, which wouldn't be broken up even under heavy load.
While this works reasonably well for most things, printing out decoded
sense with just one line (and not end up in massive switch()
statements) is near impossible.
Plus you'll end up having to use a static buffer at one point, which
again increases the stack size.
The alternative approach as discussed at LSF is to move scsi_logging
over to tracing. There is already some coding for scsi tracing, but
Oh, I didn't attend the meeting, so I didn't know it.
Did you completely change the development from fixing scsi_logging
to using tracing?
in most cases it just duplicates existing logging statements.
So if we were to replace the entire scsi_logging infrastructure
with scsi tracing most of the issues (like chopped-up CDBs) would
be gone.
Plus we would have a far better control about _what_ is being printed.
And yes, I do have some patches for that :-)
I would like to develop the feature together because this
is an important problem.
Would you upload the patches to your tree?
And, would you share current status and issues with us?
Thank you,
Yoshihiro YUNOMAE
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: cris: arch-v32: drivers: axisflashmap.c: Cleaning up inconsistent NULL checks
On Fri, May 23, 2014 at 06:40:17PM +0200, Rickard Strandqvist wrote: Hej Jesper! Tjo! But in several other place in the feature ensures that main_mtd is not NULL. (That's what cppcheck base their misjudgment on too) Then all these checks are unnecessary? No, it is still necessary to check for NULL, however as I wrote in my reply, we do check for ptable_head, which is only set if main_mtd is set. You should know, looks like you've written most of the code in 2007 :) Best regards Rickard Strandqvist /Jesper 2014-05-23 9:00 GMT+02:00 Jesper Nilsson jesper.nils...@axis.com: On Fri, May 23, 2014 at 12:00:09AM +0200, Rickard Strandqvist wrote: Cleaning up inconsistent NULL checks. There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. ... and is a false positive. We can't enter this if-block unless ptable_head is set, which is only set if main_mtd is set. It might be useful to add it anyways, but there's a refactoring needed for the axisflashmaps, so I'll keep it for then. /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] drm/exynos: ipp: remove usless list_empty() functions
From: YoungJun Cho yj44@samsung.com
list_for_each_entry() handles empty lists, so there is no
need to check whether the list is empty first.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 61 +
1 file changed, 9 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index bf71d97..c8cfa24 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -276,11 +276,6 @@ static struct exynos_drm_ippdrv
*ipp_find_drv_by_handle(u32 prop_id)
DRM_DEBUG_KMS(prop_id[%d]\n, prop_id);
- if (list_empty(exynos_drm_ippdrv_list)) {
- DRM_DEBUG_KMS(ippdrv_list is empty.\n);
- return ERR_PTR(-ENODEV);
- }
-
/*
* This case is search ipp driver by prop_id handle.
* sometimes, ipp subsystem find driver by prop_id.
@@ -289,11 +284,9 @@ static struct exynos_drm_ippdrv
*ipp_find_drv_by_handle(u32 prop_id)
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
DRM_DEBUG_KMS(count[%d]ippdrv[0x%x]\n, count++, (int)ippdrv);
- if (!list_empty(ippdrv-cmd_list)) {
- list_for_each_entry(c_node, ippdrv-cmd_list, list)
- if (c_node-property.prop_id == prop_id)
- return ippdrv;
- }
+ list_for_each_entry(c_node, ippdrv-cmd_list, list)
+ if (c_node-property.prop_id == prop_id)
+ return ippdrv;
}
return ERR_PTR(-ENODEV);
@@ -573,11 +566,6 @@ static int ipp_check_mem_list(struct
drm_exynos_ipp_cmd_node *c_node)
/* source/destination memory list */
head = c_node-mem_list[i];
- if (list_empty(head)) {
- DRM_DEBUG_KMS(%s memory empty.\n, i ? dst : src);
- continue;
- }
-
/* find memory node entry */
list_for_each_entry(m_node, head, list) {
DRM_DEBUG_KMS(%s,count[%d]m_node[0x%x]\n,
@@ -816,11 +804,6 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node
*c_node,
struct drm_exynos_ipp_send_event *e, *te;
int count = 0;
- if (list_empty(c_node-event_list)) {
- DRM_DEBUG_KMS(event_list is empty.\n);
- return;
- }
-
list_for_each_entry_safe(e, te, c_node-event_list, base.link) {
DRM_DEBUG_KMS(count[%d]e[0x%x]\n, count++, (int)e);
@@ -918,14 +901,12 @@ static void ipp_clean_queue_buf(struct drm_device
*drm_dev,
{
struct drm_exynos_ipp_mem_node *m_node, *tm_node;
- if (!list_empty(c_node-mem_list[qbuf-ops_id])) {
- /* delete list */
- list_for_each_entry_safe(m_node, tm_node,
- c_node-mem_list[qbuf-ops_id], list) {
- if (m_node-buf_id == qbuf-buf_id
- m_node-ops_id == qbuf-ops_id)
- ipp_put_mem_node(drm_dev, c_node, m_node);
- }
+ /* delete list */
+ list_for_each_entry_safe(m_node, tm_node,
+ c_node-mem_list[qbuf-ops_id], list) {
+ if (m_node-buf_id == qbuf-buf_id
+ m_node-ops_id == qbuf-ops_id)
+ ipp_put_mem_node(drm_dev, c_node, m_node);
}
}
@@ -1361,11 +1342,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* source/destination memory list */
head = c_node-mem_list[i];
- if (list_empty(head)) {
- DRM_DEBUG_KMS(mem_list is empty.\n);
- break;
- }
-
list_for_each_entry_safe(m_node, tm_node,
head, list) {
ret = ipp_put_mem_node(drm_dev, c_node,
@@ -1381,11 +1357,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* destination memory list */
head = c_node-mem_list[EXYNOS_DRM_OPS_DST];
- if (list_empty(head)) {
- DRM_DEBUG_KMS(mem_list is empty.\n);
- break;
- }
-
list_for_each_entry_safe(m_node, tm_node, head, list) {
ret = ipp_put_mem_node(drm_dev, c_node, m_node);
if (ret) {
@@ -1398,11 +1369,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* source memory list */
head = c_node-mem_list[EXYNOS_DRM_OPS_SRC];
- if
[PATCH 0/9] drm/exynos/ipp: image post processing improvements, part deux
This is the next part of ipp improvement patches, this time made by YoungJun Cho, I am posting them as he is on leave. The patchset is based on drm-exynos/exynos-drm-next branch. Regards Andrzej Andrzej Hajda (1): drm/exynos: ipp: remove description of non-existing field YoungJun Cho (8): drm/exynos: ipp: remove usless list_empty() functions drm/exynos: ipp: remove duplicated setting drm/exynos: ipp: rename cmd_lock to lock drm/exynos: ipp: add cmd_lock for cmd_list drm/exynos: ipp: add ipp_remove_id() drm/exynos: ipp: rearrange c_node-mem_lock using routines drm/exynos: ipp: rearrange c_node-event_lock using routine drm/exynos: ipp: update comment for struct drm_ipp_buf_info drivers/gpu/drm/exynos/exynos_drm_ipp.c | 242 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 9 +- 2 files changed, 129 insertions(+), 122 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] drm/exynos: ipp: add ipp_remove_id()
From: YoungJun Cho yj44@samsung.com
This patch adds ipp_remove_id() for idr resource free.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 42 -
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b60ae54..f1c51b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -167,6 +167,13 @@ static int ipp_create_id(struct idr *id_idr, struct mutex
*lock, void *obj,
return 0;
}
+static void ipp_remove_id(struct idr *id_idr, struct mutex *lock, u32 id)
+{
+ mutex_lock(lock);
+ idr_remove(id_idr, id);
+ mutex_unlock(lock);
+}
+
static void *ipp_find_obj(struct idr *id_idr, struct mutex *lock, u32 id)
{
void *obj;
@@ -501,7 +508,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
c_node-start_work = ipp_create_cmd_work();
if (IS_ERR(c_node-start_work)) {
DRM_ERROR(failed to create start work.\n);
- goto err_clear;
+ goto err_remove_id;
}
c_node-stop_work = ipp_create_cmd_work();
@@ -542,16 +549,22 @@ err_free_stop:
kfree(c_node-stop_work);
err_free_start:
kfree(c_node-start_work);
+err_remove_id:
+ ipp_remove_id(ctx-prop_idr, ctx-prop_lock, property-prop_id);
err_clear:
kfree(c_node);
return ret;
}
-static void ipp_clean_cmd_node(struct drm_exynos_ipp_cmd_node *c_node)
+static void ipp_clean_cmd_node(struct ipp_context *ctx,
+ struct drm_exynos_ipp_cmd_node *c_node)
{
/* delete list */
list_del(c_node-list);
+ ipp_remove_id(ctx-prop_idr, ctx-prop_lock,
+ c_node-property.prop_id);
+
/* destroy mutex */
mutex_destroy(c_node-lock);
mutex_destroy(c_node-mem_lock);
@@ -1122,7 +1135,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
void *data,
c_node-state = IPP_STATE_STOP;
ippdrv-dedicated = false;
mutex_lock(ippdrv-cmd_lock);
- ipp_clean_cmd_node(c_node);
+ ipp_clean_cmd_node(ctx, c_node);
if (list_empty(ippdrv-cmd_list))
pm_runtime_put_sync(ippdrv-dev);
@@ -1686,7 +1699,7 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
ipp_id);
if (ret || ipp_id == 0) {
DRM_ERROR(failed to create id.\n);
- goto err_idr;
+ goto err;
}
DRM_DEBUG_KMS(count[%d]ippdrv[0x%x]ipp_id[%d]\n,
@@ -1707,34 +1720,40 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
ret = drm_iommu_attach_device(drm_dev, ippdrv-dev);
if (ret) {
DRM_ERROR(failed to activate iommu\n);
- goto err_iommu;
+ goto err;
}
}
}
return 0;
-err_iommu:
+err:
/* get ipp driver entry */
- list_for_each_entry_reverse(ippdrv, exynos_drm_ippdrv_list, drv_list)
+ list_for_each_entry_continue_reverse(ippdrv, exynos_drm_ippdrv_list,
+ drv_list) {
if (is_drm_iommu_supported(drm_dev))
drm_iommu_detach_device(drm_dev, ippdrv-dev);
-err_idr:
- idr_destroy(ctx-ipp_idr);
- idr_destroy(ctx-prop_idr);
+ ipp_remove_id(ctx-ipp_idr, ctx-ipp_lock,
+ ippdrv-prop_list.ipp_id);
+ }
+
return ret;
}
static void ipp_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
struct exynos_drm_ippdrv *ippdrv;
+ struct ipp_context *ctx = get_ipp_context(dev);
/* get ipp driver entry */
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
if (is_drm_iommu_supported(drm_dev))
drm_iommu_detach_device(drm_dev, ippdrv-dev);
+ ipp_remove_id(ctx-ipp_idr, ctx-ipp_lock,
+ ippdrv-prop_list.ipp_id);
+
ippdrv-drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
@@ -1765,6 +1784,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev,
struct device *dev,
struct drm_exynos_file_private *file_priv = file-driver_priv;
struct exynos_drm_ipp_private *priv = file_priv-ipp_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
+ struct ipp_context *ctx =
[PATCH 4/9] drm/exynos: ipp: add cmd_lock for cmd_list
From: YoungJun Cho yj44@samsung.com
This patch adds cmd_lock for cmd_list synchronization.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 20 ++--
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 0d85433..b60ae54 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -284,9 +284,14 @@ static struct exynos_drm_ippdrv
*ipp_find_drv_by_handle(u32 prop_id)
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
DRM_DEBUG_KMS(count[%d]ippdrv[0x%x]\n, count++, (int)ippdrv);
- list_for_each_entry(c_node, ippdrv-cmd_list, list)
- if (c_node-property.prop_id == prop_id)
+ mutex_lock(ippdrv-cmd_lock);
+ list_for_each_entry(c_node, ippdrv-cmd_list, list) {
+ if (c_node-property.prop_id == prop_id) {
+ mutex_unlock(ippdrv-cmd_lock);
return ippdrv;
+ }
+ }
+ mutex_unlock(ippdrv-cmd_lock);
}
return ERR_PTR(-ENODEV);
@@ -318,6 +323,7 @@ int exynos_drm_ipp_get_property(struct drm_device *drm_dev,
void *data,
if (!prop_list-ipp_id) {
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list)
count++;
+
/*
* Supports ippdrv list count for user application.
* First step user application getting ippdrv count.
@@ -379,9 +385,11 @@ static int ipp_find_and_set_property(struct
drm_exynos_ipp_property *property)
* when we find this command no using prop_id.
* return property information set in this command node.
*/
+ mutex_lock(ippdrv-cmd_lock);
list_for_each_entry(c_node, ippdrv-cmd_list, list) {
if ((c_node-property.prop_id == prop_id)
(c_node-state == IPP_STATE_STOP)) {
+ mutex_unlock(ippdrv-cmd_lock);
DRM_DEBUG_KMS(found cmd[%d]ippdrv[0x%x]\n,
property-cmd, (int)ippdrv);
@@ -389,6 +397,7 @@ static int ipp_find_and_set_property(struct
drm_exynos_ipp_property *property)
return 0;
}
}
+ mutex_unlock(ippdrv-cmd_lock);
DRM_ERROR(failed to search property.\n);
@@ -519,7 +528,9 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
INIT_LIST_HEAD(c_node-event_list);
list_splice_init(priv-event_list, c_node-event_list);
+ mutex_lock(ippdrv-cmd_lock);
list_add_tail(c_node-list, ippdrv-cmd_list);
+ mutex_unlock(ippdrv-cmd_lock);
/* make dedicated state without m2m */
if (!ipp_is_m2m_cmd(property-cmd))
@@ -1110,10 +1121,12 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
void *data,
c_node-state = IPP_STATE_STOP;
ippdrv-dedicated = false;
+ mutex_lock(ippdrv-cmd_lock);
ipp_clean_cmd_node(c_node);
if (list_empty(ippdrv-cmd_list))
pm_runtime_put_sync(ippdrv-dev);
+ mutex_unlock(ippdrv-cmd_lock);
break;
case IPP_CTRL_PAUSE:
cmd_work = c_node-stop_work;
@@ -1688,6 +1701,7 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
ippdrv-event_workq = ctx-event_workq;
ippdrv-sched_event = ipp_sched_event;
INIT_LIST_HEAD(ippdrv-cmd_list);
+ mutex_init(ippdrv-cmd_lock);
if (is_drm_iommu_supported(drm_dev)) {
ret = drm_iommu_attach_device(drm_dev, ippdrv-dev);
@@ -1757,6 +1771,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev,
struct device *dev,
DRM_DEBUG_KMS(for priv[0x%x]\n, (int)priv);
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
+ mutex_lock(ippdrv-cmd_lock);
list_for_each_entry_safe(c_node, tc_node,
ippdrv-cmd_list, list) {
DRM_DEBUG_KMS(count[%d]ippdrv[0x%x]\n,
@@ -1781,6 +1796,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev,
struct device *dev,
pm_runtime_put_sync(ippdrv-dev);
}
}
+ mutex_unlock(ippdrv-cmd_lock);
}
kfree(priv);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index fbb80ac..09cb5a2
[PATCH 6/9] drm/exynos: ipp: rearrange c_node-mem_lock using routines
From: YoungJun Cho yj44@samsung.com
The c_node-mem_list[] should be protected with
c_node-mem_lock.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 86 ++---
1 file changed, 48 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index f1c51b4..4b5afd3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -584,8 +584,6 @@ static int ipp_check_mem_list(struct
drm_exynos_ipp_cmd_node *c_node)
struct list_head *head;
int ret, i, count[EXYNOS_DRM_OPS_MAX] = { 0, };
- mutex_lock(c_node-mem_lock);
-
for_each_ipp_ops(i) {
/* source/destination memory list */
head = c_node-mem_list[i];
@@ -614,8 +612,6 @@ static int ipp_check_mem_list(struct
drm_exynos_ipp_cmd_node *c_node)
ret = max(count[EXYNOS_DRM_OPS_SRC],
count[EXYNOS_DRM_OPS_DST]);
- mutex_unlock(c_node-mem_lock);
-
return ret;
}
@@ -658,16 +654,13 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
*ippdrv,
return -EFAULT;
}
- mutex_lock(c_node-mem_lock);
-
DRM_DEBUG_KMS(ops_id[%d]\n, m_node-ops_id);
/* get operations callback */
ops = ippdrv-ops[m_node-ops_id];
if (!ops) {
DRM_ERROR(not support ops.\n);
- ret = -EFAULT;
- goto err_unlock;
+ return -EFAULT;
}
/* set address and enable irq */
@@ -676,12 +669,10 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
*ippdrv,
m_node-buf_id, IPP_BUF_ENQUEUE);
if (ret) {
DRM_ERROR(failed to set addr.\n);
- goto err_unlock;
+ return ret;
}
}
-err_unlock:
- mutex_unlock(c_node-mem_lock);
return ret;
}
@@ -696,11 +687,9 @@ static struct drm_exynos_ipp_mem_node
void *addr;
int i;
- mutex_lock(c_node-mem_lock);
-
m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
if (!m_node)
- goto err_unlock;
+ return ERR_PTR(-ENOMEM);
/* clear base address for error handling */
memset(buf_info, 0x0, sizeof(buf_info));
@@ -734,15 +723,14 @@ static struct drm_exynos_ipp_mem_node
m_node-filp = file;
m_node-buf_info = buf_info;
+ mutex_lock(c_node-mem_lock);
list_add_tail(m_node-list, c_node-mem_list[qbuf-ops_id]);
-
mutex_unlock(c_node-mem_lock);
+
return m_node;
err_clear:
kfree(m_node);
-err_unlock:
- mutex_unlock(c_node-mem_lock);
return ERR_PTR(-EFAULT);
}
@@ -759,13 +747,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
return -EFAULT;
}
- if (list_empty(m_node-list)) {
- DRM_ERROR(empty memory node.\n);
- return -ENOMEM;
- }
-
- mutex_lock(c_node-mem_lock);
-
DRM_DEBUG_KMS(ops_id[%d]\n, m_node-ops_id);
/* put gem buffer */
@@ -780,8 +761,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
list_del(m_node-list);
kfree(m_node);
- mutex_unlock(c_node-mem_lock);
-
return 0;
}
@@ -894,7 +873,9 @@ static int ipp_queue_buf_with_run(struct device *dev,
return 0;
}
+ mutex_lock(c_node-mem_lock);
if (!ipp_check_mem_list(c_node)) {
+ mutex_unlock(c_node-mem_lock);
DRM_DEBUG_KMS(empty memory.\n);
return 0;
}
@@ -911,10 +892,12 @@ static int ipp_queue_buf_with_run(struct device *dev,
} else {
ret = ipp_set_mem_node(ippdrv, c_node, m_node);
if (ret) {
+ mutex_unlock(c_node-mem_lock);
DRM_ERROR(failed to set m node.\n);
return ret;
}
}
+ mutex_unlock(c_node-mem_lock);
return 0;
}
@@ -926,12 +909,14 @@ static void ipp_clean_queue_buf(struct drm_device
*drm_dev,
struct drm_exynos_ipp_mem_node *m_node, *tm_node;
/* delete list */
+ mutex_lock(c_node-mem_lock);
list_for_each_entry_safe(m_node, tm_node,
c_node-mem_list[qbuf-ops_id], list) {
if (m_node-buf_id == qbuf-buf_id
m_node-ops_id == qbuf-ops_id)
ipp_put_mem_node(drm_dev, c_node, m_node);
}
+ mutex_unlock(c_node-mem_lock);
}
int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data,
@@ -1267,9 +1252,11 @@ static int ipp_start_property(struct exynos_drm_ippdrv
[PATCH 8/9] drm/exynos: ipp: update comment for struct drm_ipp_buf_info
From: YoungJun Cho yj44@samsung.com
The attribute gem_objs in struct drm_exynos_ipp_buf_info was
changed to handles. So the comment needs to be updated also.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 09cb5a2..e06c41e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -83,7 +83,7 @@ struct drm_exynos_ipp_cmd_node {
/*
* A structure of buffer information.
*
- * @gem_objs: Y, Cb, Cr each gem object.
+ * @handles: Y, Cb, Cr each gem object handle.
* @base: Y, Cb, Cr each planar address.
*/
struct drm_exynos_ipp_buf_info {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] drm/exynos: ipp: rearrange c_node-event_lock using routine
From: YoungJun Cho yj44@samsung.com
The c_node-event_list should be protected with
c_node-event_lock.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 4b5afd3..603a796 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -796,7 +796,9 @@ static int ipp_get_event(struct drm_device *drm_dev,
e-base.event = e-event.base;
e-base.file_priv = file;
e-base.destroy = ipp_free_event;
+ mutex_lock(c_node-event_lock);
list_add_tail(e-base.link, c_node-event_list);
+ mutex_unlock(c_node-event_lock);
return 0;
}
@@ -807,6 +809,7 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node
*c_node,
struct drm_exynos_ipp_send_event *e, *te;
int count = 0;
+ mutex_lock(c_node-event_lock);
list_for_each_entry_safe(e, te, c_node-event_list, base.link) {
DRM_DEBUG_KMS(count[%d]e[0x%x]\n, count++, (int)e);
@@ -827,9 +830,13 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node
*c_node,
/* delete list */
list_del(e-base.link);
kfree(e);
- return;
+ goto out_unlock;
}
}
+
+out_unlock:
+ mutex_unlock(c_node-event_lock);
+ return;
}
static void ipp_handle_cmd_work(struct device *dev,
@@ -1515,9 +1522,11 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
return -EINVAL;
}
+ mutex_lock(c_node-event_lock);
if (list_empty(c_node-event_list)) {
DRM_DEBUG_KMS(event list is empty.\n);
- return 0;
+ ret = 0;
+ goto err_event_unlock;
}
mutex_lock(c_node-mem_lock);
@@ -1609,11 +1618,6 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
e = list_first_entry(c_node-event_list,
struct drm_exynos_ipp_send_event, base.link);
- if (!e) {
- DRM_ERROR(empty event.\n);
- return -EINVAL;
- }
-
do_gettimeofday(now);
DRM_DEBUG_KMS(tv_sec[%ld]tv_usec[%ld]\n, now.tv_sec, now.tv_usec);
e-event.tv_sec = now.tv_sec;
@@ -1628,6 +1632,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
list_move_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
spin_unlock_irqrestore(drm_dev-event_lock, flags);
+ mutex_unlock(c_node-event_lock);
DRM_DEBUG_KMS(done cmd[%d]prop_id[%d]buf_id[%d]\n,
property-cmd, property-prop_id, tbuf_id[EXYNOS_DRM_OPS_DST]);
@@ -1636,6 +1641,8 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
err_mem_unlock:
mutex_unlock(c_node-mem_lock);
+err_event_unlock:
+ mutex_unlock(c_node-event_lock);
return ret;
}
@@ -1678,8 +1685,6 @@ void ipp_sched_event(struct work_struct *work)
goto err_completion;
}
- mutex_lock(c_node-event_lock);
-
ret = ipp_send_event(ippdrv, c_node, event_work-buf_id);
if (ret) {
DRM_ERROR(failed to send event.\n);
@@ -1689,8 +1694,6 @@ void ipp_sched_event(struct work_struct *work)
err_completion:
if (ipp_is_m2m_cmd(c_node-property.cmd))
complete(c_node-start_complete);
-
- mutex_unlock(c_node-event_lock);
}
static int ipp_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] drm/exynos: ipp: remove description of non-existing field
ipp_id field is removed from exynos_drm_ippdrv struct.
The patch removes its description as well.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index e06c41e..7aaeaae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -142,7 +142,6 @@ struct exynos_drm_ipp_ops {
* @parent_dev: parent device information.
* @dev: platform device.
* @drm_dev: drm device.
- * @ipp_id: id of ipp driver.
* @dedicated: dedicated ipp device.
* @ops: source, destination operations.
* @event_workq: event work queue.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] drm/exynos: ipp: remove duplicated setting
From: YoungJun Cho yj44@samsung.com This patch removes duplicated setting. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Seong-Woo Kim sw0312@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Tested-by: Andrzej Hajda a.ha...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index c8cfa24..0968777 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -1090,12 +1090,12 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, void *data, case IPP_CTRL_PLAY: if (pm_runtime_suspended(ippdrv-dev)) pm_runtime_get_sync(ippdrv-dev); + c_node-state = IPP_STATE_START; cmd_work = c_node-start_work; cmd_work-ctrl = cmd_ctrl-ctrl; ipp_handle_cmd_work(dev, ippdrv, cmd_work, c_node); - c_node-state = IPP_STATE_START; break; case IPP_CTRL_STOP: cmd_work = c_node-stop_work; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] drm/exynos: ipp: rename cmd_lock to lock
From: YoungJun Cho yj44@samsung.com
The ippdrv-cmd_list requires cmd_lock.
So renames cmd_lock to lock for context.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Seong-Woo Kim sw0312@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 ++--
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 0968777..0d85433 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -507,7 +507,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
goto err_free_stop;
}
- mutex_init(c_node-cmd_lock);
+ mutex_init(c_node-lock);
mutex_init(c_node-mem_lock);
mutex_init(c_node-event_lock);
@@ -542,7 +542,7 @@ static void ipp_clean_cmd_node(struct
drm_exynos_ipp_cmd_node *c_node)
list_del(c_node-list);
/* destroy mutex */
- mutex_destroy(c_node-cmd_lock);
+ mutex_destroy(c_node-lock);
mutex_destroy(c_node-mem_lock);
mutex_destroy(c_node-event_lock);
@@ -979,7 +979,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
}
break;
case IPP_BUF_DEQUEUE:
- mutex_lock(c_node-cmd_lock);
+ mutex_lock(c_node-lock);
/* put event for destination buffer */
if (qbuf-ops_id == EXYNOS_DRM_OPS_DST)
@@ -987,7 +987,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
ipp_clean_queue_buf(drm_dev, c_node, qbuf);
- mutex_unlock(c_node-cmd_lock);
+ mutex_unlock(c_node-lock);
break;
default:
DRM_ERROR(invalid buffer control.\n);
@@ -1412,7 +1412,7 @@ void ipp_sched_cmd(struct work_struct *work)
return;
}
- mutex_lock(c_node-cmd_lock);
+ mutex_lock(c_node-lock);
property = c_node-property;
@@ -1460,7 +1460,7 @@ void ipp_sched_cmd(struct work_struct *work)
DRM_DEBUG_KMS(ctrl[%d] done.\n, cmd_work-ctrl);
err_unlock:
- mutex_unlock(c_node-cmd_lock);
+ mutex_unlock(c_node-lock);
}
static int ipp_send_event(struct exynos_drm_ippdrv *ippdrv,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index eea4db3..fbb80ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -52,7 +52,7 @@ struct drm_exynos_ipp_cmd_work {
* @list: list head to command queue information.
* @event_list: list head of event.
* @mem_list: list head to source,destination memory queue information.
- * @cmd_lock: lock for synchronization of access to ioctl.
+ * @lock: lock for synchronization of access to ioctl.
* @mem_lock: lock for synchronization of access to memory nodes.
* @event_lock: lock for synchronization of access to scheduled event.
* @start_complete: completion of start of command.
@@ -68,7 +68,7 @@ struct drm_exynos_ipp_cmd_node {
struct list_headlist;
struct list_headevent_list;
struct list_headmem_list[EXYNOS_DRM_OPS_MAX];
- struct mutexcmd_lock;
+ struct mutexlock;
struct mutexmem_lock;
struct mutexevent_lock;
struct completion start_complete;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/11][V2] kexec: A new system call to allow in kernel loading
Hi Vivek, On Mon, Jan 27, 2014 at 01:57:40PM -0500, Vivek Goyal wrote: Hi This is V2 of new system call patches. Previous version was posted here. just a quick ping here, are you working on a v3? Anything I can help with? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/11] ARM: topology: use new cpu_power interface
On 25 May 2014 15:22, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Hi Vincent,
Why do we have two interfaces arch_scale_freq_power() and
arch_scale_cpu_power()? Does it make sense to consolidate them now ?
Hi Preeti,
They don't have the same purpose. arch_scale_cpu_power set the max
capacity of your CPU whereas arch_scale_freq_power can be used to give
the current capacity. ARM platform were using arch_scale_freq_power
because it was the only one available for non SMT system but this
induces some misunderstanding and some limitation in the
characterization of a CPUs. This consolidation is a necessary step so
we can now have the max capacity of a CPU and let
arch_scale_freq_power for other purpose (or even remove it if
useless).
Regards,
Vincent
Regards
Preeti U Murthy
On 05/23/2014 09:22 PM, Vincent Guittot wrote:
Use the new arch_scale_cpu_power in order to reflect the original capacity of
a CPU instead of arch_scale_freq_power which is more linked to a scaling of
the capacity linked to the frequency.
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
arch/arm/kernel/topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 71e1fec..6cc25a8 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -42,7 +42,7 @@
*/
static DEFINE_PER_CPU(unsigned long, cpu_scale);
-unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu)
+unsigned long arch_scale_cpu_power(struct sched_domain *sd, int cpu)
{
return per_cpu(cpu_scale, cpu);
}
@@ -166,7 +166,7 @@ static void update_cpu_power(unsigned int cpu)
set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
printk(KERN_INFO CPU%u: update cpu_power %lu\n,
- cpu, arch_scale_freq_power(NULL, cpu));
+ cpu, arch_scale_cpu_power(NULL, cpu));
}
#else
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] regulator: s2mpa01: Use correct register for buck1 ramp delay
Fix the register for ramp delay of buck1 regulator. Buck1 and buck6 share the field (offset 4) in ramp delay register S2MPA01_REG_RAMP2. The driver used the same register and field for ramp delay of buck3 and buck1. This lead to updating of ramp delay of buck3 when setting buck1 and actually the ramp delay of buck1 was never set. Cc: sta...@vger.kernel.org Fixes: f18792714608 (regulator: Add support for S2MPA01 regulator) Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- Changes since v1: 1. Adjust the patch to match datasheet of S2MPA01. --- drivers/regulator/s2mpa01.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c index f19a30f0fb42..a52cb1cec576 100644 --- a/drivers/regulator/s2mpa01.c +++ b/drivers/regulator/s2mpa01.c @@ -116,7 +116,6 @@ static int s2mpa01_set_ramp_delay(struct regulator_dev *rdev, int ramp_delay) ramp_delay = s2mpa01-ramp_delay16; ramp_shift = S2MPA01_BUCK16_RAMP_SHIFT; - ramp_reg = S2MPA01_REG_RAMP1; break; case S2MPA01_BUCK2: enable_shift = S2MPA01_BUCK2_RAMP_EN_SHIFT; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ASoC: max98095: Add master clock handling
If master clock is provided through device tree, then update
the master clock frequency during set_sysclk.
Documentation has been updated to reflect the change.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
.../devicetree/bindings/sound/max98095.txt |6 +
sound/soc/codecs/max98095.c| 24
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/max98095.txt
b/Documentation/devicetree/bindings/sound/max98095.txt
index bacbeaa..318a4c8 100644
--- a/Documentation/devicetree/bindings/sound/max98095.txt
+++ b/Documentation/devicetree/bindings/sound/max98095.txt
@@ -8,6 +8,12 @@ Required properties:
- reg : The I2C address of the device.
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be mclk
+
Example:
max98095: codec@11 {
diff --git a/sound/soc/codecs/max98095.c b/sound/soc/codecs/max98095.c
index d6c1e4c..89ec004 100644
--- a/sound/soc/codecs/max98095.c
+++ b/sound/soc/codecs/max98095.c
@@ -15,6 +15,7 @@
#include linux/delay.h
#include linux/pm.h
#include linux/i2c.h
+#include linux/clk.h
#include sound/core.h
#include sound/pcm.h
#include sound/pcm_params.h
@@ -42,6 +43,7 @@ struct max98095_priv {
struct regmap *regmap;
enum max98095_type devtype;
struct max98095_pdata *pdata;
+ struct clk *mclk;
unsigned int sysclk;
struct max98095_cdata dai[3];
const char **eq_texts;
@@ -1395,6 +1397,11 @@ static int max98095_dai_set_sysclk(struct snd_soc_dai
*dai,
if (freq == max98095-sysclk)
return 0;
+ if (!IS_ERR(max98095-mclk)) {
+ freq = clk_round_rate(max98095-mclk, freq);
+ clk_set_rate(max98095-mclk, freq);
+ }
+
/* Setup clocks for slave mode, and using the PLL
* PSCLK = 0x01 (when master clk is 10MHz to 20MHz)
* 0x02 (when master clk is 20MHz to 40MHz)..
@@ -1634,6 +1641,19 @@ static int max98095_set_bias_level(struct snd_soc_codec
*codec,
break;
case SND_SOC_BIAS_PREPARE:
+ /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+ if (!IS_ERR(max98095-mclk)) {
+ if (codec-dapm.bias_level == SND_SOC_BIAS_ON)
+ clk_disable_unprepare(max98095-mclk);
+ else
+ clk_prepare_enable(max98095-mclk);
+ }
break;
case SND_SOC_BIAS_STANDBY:
@@ -2238,6 +2258,10 @@ static int max98095_probe(struct snd_soc_codec *codec)
struct i2c_client *client;
int ret = 0;
+ max98095-mclk = devm_clk_get(codec-dev, mclk);
+ if (PTR_ERR(max98095-mclk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
/* reset the codec, the DSP core, and disable all interrupts */
max98095_reset(codec);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/2] ASoC: max98090/max98095: Add master clock handing
These CODECs are used on Snow/Peach-pit boards and the master clock needs to be set at 24MHz. Adding support in respective codec drivers so that we can update the master clock frequency from sound card driver through set_sysclk. Changes for V2: 1. Added PROBE_DEFER if clock driver has not yet been probed 2. Moved clk_prepare_enable from .probe to .set_bias_level 3. Moved clk_disable_unprepare from .remove to .set_bias_level Tushar Behera (2): ASoC: max98090: Add master clock handling ASoC: max98095: Add master clock handling .../devicetree/bindings/sound/max98090.txt |6 + .../devicetree/bindings/sound/max98095.txt |6 + sound/soc/codecs/max98090.c| 23 +++ sound/soc/codecs/max98090.h|1 + sound/soc/codecs/max98095.c| 24 5 files changed, 60 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] ASoC: max98090: Add master clock handling
If master clock is provided through device tree, then update
the master clock frequency during set_sysclk.
Documentation has been updated to reflect the change.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
.../devicetree/bindings/sound/max98090.txt |6 +
sound/soc/codecs/max98090.c| 23
sound/soc/codecs/max98090.h|1 +
3 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/max98090.txt
b/Documentation/devicetree/bindings/sound/max98090.txt
index e4c8b36..a5e63fa 100644
--- a/Documentation/devicetree/bindings/sound/max98090.txt
+++ b/Documentation/devicetree/bindings/sound/max98090.txt
@@ -10,6 +10,12 @@ Required properties:
- interrupts : The CODEC's interrupt output.
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be mclk
+
Pins on the device (for linking into audio routes):
* MIC1
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 9b76f5a..9275785 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -17,6 +17,7 @@
#include linux/regmap.h
#include linux/slab.h
#include linux/acpi.h
+#include linux/clk.h
#include sound/jack.h
#include sound/pcm.h
#include sound/pcm_params.h
@@ -1800,6 +1801,19 @@ static int max98090_set_bias_level(struct snd_soc_codec
*codec,
break;
case SND_SOC_BIAS_PREPARE:
+ /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+ if (!IS_ERR(max98090-mclk)) {
+ if (codec-dapm.bias_level == SND_SOC_BIAS_ON)
+ clk_disable_unprepare(max98090-mclk);
+ else
+ clk_prepare_enable(max98090-mclk);
+ }
break;
case SND_SOC_BIAS_STANDBY:
@@ -1929,6 +1943,11 @@ static int max98090_dai_set_sysclk(struct snd_soc_dai
*dai,
if (freq == max98090-sysclk)
return 0;
+ if (!IS_ERR(max98090-mclk)) {
+ freq = clk_round_rate(max98090-mclk, freq);
+ clk_set_rate(max98090-mclk, freq);
+ }
+
/* Setup clocks for slave mode, and using the PLL
* PSCLK = 0x01 (when master clk is 10MHz to 20MHz)
* 0x02 (when master clk is 20MHz to 40MHz)..
@@ -2213,6 +2232,10 @@ static int max98090_probe(struct snd_soc_codec *codec)
dev_dbg(codec-dev, max98090_probe\n);
+ max98090-mclk = devm_clk_get(codec-dev, mclk);
+ if (PTR_ERR(max98090-mclk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
max98090-codec = codec;
/* Reset the codec, the DSP core, and disable all interrupts */
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h
index 5a3c8d0..cf1b606 100644
--- a/sound/soc/codecs/max98090.h
+++ b/sound/soc/codecs/max98090.h
@@ -1524,6 +1524,7 @@ struct max98090_priv {
struct snd_soc_codec *codec;
enum max98090_type devtype;
struct max98090_pdata *pdata;
+ struct clk *mclk;
unsigned int sysclk;
unsigned int bclk;
unsigned int lrclk;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] i2c: add driver for Rockchip RK3xxx SoC I2C adapter
Hi,
Am Montag, 19. Mai 2014, 11:32:55 schrieb Max Schwarz:
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz max.schw...@online.de
As I just saw it, the previous Ack, was sent to the wrong patch, and was
actually meant for v4, so here it is again:
Acked-by: Heiko Stuebner he...@sntech.de
Thanks
Heiko
---
The driver cannot be used without a proper clock driver
supporting rate calculation, such as Heiko Stübner's RK3xxx clock
driver series [1].
Changes since v3:
- fixed style issues found by Maxime Ripard
- use dt alias id to calculate the bit offset in GRF,
as suggested by Maxime Ripard
- also use dt alias id for i2c_add_numbered_adapter()
Changes since v2:
- support for the new GRF syscon mapping by Heiko Stübner
- probe error handling improvements by Heiko Stübner
- fixed wrong remove() order found by Heiko Stübner
- removed unnecessary clk_enable() during probe
- removed switch back to old interface during remove
Changes since v1:
- dt property names rockchip,* suggested by Heiko Stübner
- fixed overly specific RK3188 comment (Heiko Stübner)
The dts files needed for testing on Radxa Rock are in my tree at
https://github.com/xqms/linux.git topic/i2c-rk3x-clean-v4
[1]: http://www.spinics.net/lists/arm-kernel/msg329102.html
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 42 ++
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-rk3x.c | 742
+ 4 files changed, 795 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
create mode 100644 drivers/i2c/busses/i2c-rk3x.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt new file mode 100644
index 000..dde6c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -0,0 +1,42 @@
+* Rockchip RK3xxx I2C controller
+
+This driver interfaces with the native I2C controller present in Rockchip
+RK3xxx SoCs.
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device
+ - compatible : should be rockchip,rk3066-i2c, rockchip,rk3188-i2c or
+ rockchip,rk3288-i2c.
+ - interrupts : interrupt number
+ - clocks : parent clock
+
+Required on RK3066, RK3188 :
+
+ - rockchip,grf : the phandle of the syscon node for the general register
+ file (GRF)
+ - on those SoCs an alias with the correct I2C bus ID (bit offset in the
GRF) + is also required.
+
+Optional properties :
+
+ - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is
used. +
+Example:
+
+aliases {
+ i2c0 = i2c0;
+}
+
+i2c0: i2c@2002d000 {
+ compatible = rockchip,rk3188-i2c;
+ reg = 0x2002d000 0x1000;
+ interrupts = GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ rockchip,grf = grf;
+
+ clock-names = i2c;
+ clocks = cru PCLK_I2C0;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..f973632 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -663,6 +663,16 @@ config I2C_PXA_SLAVE
is necessary for systems where the PXA may be a target on the
I2C bus.
+config I2C_RK3X
+ tristate Rockchip RK3xxx I2C adapter
+ depends on OF
+ help
+ Say Y here to include support for the I2C adapter in Rockchip RK3xxx
+ SoCs.
+
+ This driver can also be built as a module. If so, the module will
+ be called i2c-rk3x.
+
config I2C_QUP
tristate Qualcomm QUP based I2C controller
depends on ARCH_QCOM
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..39b6851 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o
obj-$(CONFIG_I2C_PXA)+= i2c-pxa.o
obj-$(CONFIG_I2C_PXA_PCI)+= i2c-pxa-pci.o
+obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
obj-$(CONFIG_I2C_QUP)+= i2c-qup.o
obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
obj-$(CONFIG_I2C_S3C2410)+= i2c-s3c2410.o
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
new file mode 100644
index 000..429983b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -0,0 +1,742 @@
+/*
+ * Driver for I2C adapter in Rockchip RK3xxx SoC
+ *
+ * Max Schwarz max.schw...@online.de
+ * based on the patches by Rockchip Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the
Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration
On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
On some systems the platform doesn't support neither
PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
only available system sleep state. However, some user space frameworks
only use the mem and (sometimes) standby sleep state labels, so
the users of those systems need to modify user space in order to be
able to use system suspend at all and that is not always possible.
So, is this going to be a temporary solution until all the user-space
frameworks have been fixed? I certainly hope so, because this clearly looks
like a bug (or a lack of feature) in user-space to me... in the sense that
those user-space frameworks don't have support for (i.e., don't know how to
deal with) freeze-only systems yet.
The more elegant long term solution would have been to teach the kernel to
export *truly* relative names such as SUSPEND_DEEP, SUSPEND_SHALLOW,
and SUSPEND_LIGHT or something like that (of course, we can debate on what
naming would suit best).
But this patch continues to keep the names 'SUSPEND_MEM' (mem) etc., which
still implies that we are doing Suspend-to-RAM, because the name itself betrays
that info. So IMHO it doesn't really match what the command-line-switch
'relative_sleep_states' says.
But I understand that this is a quick hack to make existing user-space work
with systems that support only the freeze state. However, for the reasons
mentioned above, I hope that this is a temporary solution and we can remove
or enhance this once all those user-space frameworks have been fixed.
Regards,
Srivatsa S. Bhat
For this reason, add a new kernel command line argument,
relative_sleep_states, allowing the users of those systems to change
the way in which the kernel assigns labels to system sleep states.
Namely, for relative_sleep_states=1, the mem, standby and freeze
labels will enumerate the available system sleem states from the
deepest to the shallowest, respectively, so that mem is always
present in /sys/power/state and the other state strings may or may
not be presend depending on what is supported by the platform.
Update system sleep states documentation to reflect this change.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
This update is needed after patch [2/3] has been updated.
Thanks!
---
Documentation/ABI/testing/sysfs-power | 29 +++
Documentation/kernel-parameters.txt |7 ++
Documentation/power/states.txt| 89
+-
kernel/power/main.c | 12 ++--
kernel/power/suspend.c| 33 +++-
5 files changed, 120 insertions(+), 50 deletions(-)
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -86,19 +86,46 @@ static bool valid_state(suspend_state_t
return suspend_ops suspend_ops-valid suspend_ops-valid(state);
}
+/*
+ * If this is set, the mem label always corresponds to the deepest sleep
state
+ * available, the standby label corresponds to the second deepest sleep
state
+ * available (if any), and the freeze label corresponds to the remaining
+ * available sleep state (if there is one).
+ */
+static bool relative_states;
+
+static int __init sleep_states_setup(char *str)
+{
+ relative_states = !strncmp(str, 1, 1);
+ if (relative_states) {
+ pm_states[PM_SUSPEND_MEM].state = PM_SUSPEND_FREEZE;
+ pm_states[PM_SUSPEND_FREEZE].state = 0;
+ }
+ return 1;
+}
+
+__setup(relative_sleep_states=, sleep_states_setup);
+
/**
* suspend_set_ops - Set the global suspend method table.
* @ops: Suspend operations to use.
*/
void suspend_set_ops(const struct platform_suspend_ops *ops)
{
- suspend_state_t i;
+ suspend_state_t i, j = PM_SUSPEND_MAX - 1;
lock_system_sleep();
suspend_ops = ops;
- for (i = PM_SUSPEND_STANDBY; i = PM_SUSPEND_MEM; i++)
- pm_states[i].state = valid_state(i) ? i : 0;
+ for (i = PM_SUSPEND_MEM; i = PM_SUSPEND_STANDBY; i--)
+ if (valid_state(i))
+ pm_states[j--].state = i;
+ else if (!relative_states)
+ pm_states[j--].state = 0;
+
+ pm_states[j--].state = PM_SUSPEND_FREEZE;
+ while (j = PM_SUSPEND_MIN)
+ pm_states[j--].state = 0;
unlock_system_sleep();
}
Index: linux-pm/Documentation/kernel-parameters.txt
===
--- linux-pm.orig/Documentation/kernel-parameters.txt
+++ linux-pm/Documentation/kernel-parameters.txt
@@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes
[KNL, SMP] Set scheduler's default relax_domain_level.
See
Re: [RFT PATCH] regulator: s2mpa01: Use correct register for buck[36] ramp delay
On pon, 2014-05-26 at 13:37 +0530, Sachin Kamat wrote: Hi Krzysztof Apologies for the delay. I was on vacation during the early part of this month and got busy with some other stuff later and this mail fell through the cracks. On 23 May 2014 19:49, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi Sachin, The s2mpa01 regulator driver uses wrong registers for ramp delay (buck1 and buck3 in RAMP1, buck6 in RAMP2) but I am not sure which layout is proper (it seems that that buck1 should be in RAMP2 register). Could you check in S2MPA01 datasheet the registers for ramp delay for buck1, buck3 and buck6? I checked the datasheet available with me and according to it buck 1 and 6 share the ramp register 0x11 (RAMP2) (bit 4 and 5) and buck 3 uses bit 4 and 5 of register 0x10 (RAMP1). Thanks! I'll send updated version of the patchset. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
color box, display box, corrugated box, color card, blister card, color sleeve, hang tag, label
Hi, this is David Wu from Shanghai, China. We are a printing company, we can print color box, corrugated box, label, hang tag etc. Please let me know if you need these. I will send you the website then. Best regards, David Wu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: Debug: Add labels for HID Sensor Usages
On Sat, 24 May 2014, Jonathan Cameron wrote: This looks reasonable to me, but I haven't checked every entry. Also Reyad, you need to sign off on the patch if you expect anyone to pick it up. Jiri, this is one for you. (note Jiri should probably have been cc'd in the first place as the HID maintainer - unless he specifically asked not to be). I definitely want (and need) to be CCed on such patches, thanks for letting me know, Jonathan. Reyad, please add you signoff as Jonathan said, and resend the patch properly to me. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] regulator: ltc3589: Add DT binding documentation
This patch adds the device tree binding documentation for Linear
Technology LTC3589, LTC3589-1, and LTC3589-2 8-port regulators.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v1:
- Changed vendor prefix to lltc
---
.../devicetree/bindings/regulator/ltc3589.txt | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/ltc3589.txt
diff --git a/Documentation/devicetree/bindings/regulator/ltc3589.txt
b/Documentation/devicetree/bindings/regulator/ltc3589.txt
new file mode 100644
index 000..8010530
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3589.txt
@@ -0,0 +1,99 @@
+Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-output regulators
+
+Required properties:
+- compatible: lltc,ltc3589, lltc,ltc3589-1 or lltc,ltc3589-2
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains eight regulator child nodes sw1, sw2, sw3, bb-out,
+ ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as
+ documented in Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for sw1, sw2, sw3, bb-out, ldo1, and ldo2 additionally need to specify
+the resistor values of their external feedback voltage dividers:
+
+Required properties (not on ldo3, ldo4):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+ values R1 and R2 of the feedback voltage divider in ohms.
+
+Regulators sw1, sw2, sw3, and ldo2 can regulate the feedback reference from
+0.3625 V to 0.75 V in 12.5 mV steps. The output voltage thus ranges between
+0.3625 * (1 + R1/R2) V and 0.75 * (1 + R1/R2) V. Regulators bb-out and ldo1
+have a fixed 0.8 V reference and thus output 0.8 * (1 + R1/R2) V. The ldo3
+regulator is fixed to 1.8 V on LTC3589 and to 2.8 V on LTC3589-1,2. The ldo4
+regulator can output between 1.8 V and 3.3 V on LTC3589 and between 1.2 V
+and 3.2 V on LTC3589-1,2 in four steps. The ldo1 standby regulator can not
+be disabled and thus should have the regulator-always-on property set.
+
+Example:
+
+ ltc3589: pmic@34 {
+ compatible = lltc,ltc3589-1;
+ reg = 0x34;
+
+ regulators {
+ sw1_reg: sw1 {
+ regulator-min-microvolt = 591930;
+ regulator-max-microvolt = 1224671;
+ lltc,fb-voltage-divider = 10 158000;
+ regulator-ramp-delay = 7000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = 704123;
+ regulator-max-microvolt = 1456803;
+ lltc,fb-voltage-divider = 18 191000;
+ regulator-ramp-delay = 7000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3_reg: sw3 {
+ regulator-min-microvolt = 1341250;
+ regulator-max-microvolt = 2775000;
+ lltc,fb-voltage-divider = 27 10;
+ regulator-ramp-delay = 7000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ bb_out_reg: bb-out {
+ regulator-min-microvolt = 3387341;
+ regulator-max-microvolt = 3387341;
+ lltc,fb-voltage-divider = 511000 158000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 1306329;
+ regulator-max-microvolt = 1306329;
+ lltc,fb-voltage-divider = 10 158000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 704123;
+ regulator-max-microvolt = 1456806;
+ lltc,fb-voltage-divider = 18 191000;
+ regulator-ramp-delay = 7000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+
[PATCH v2 3/3] regulator: Add LTC3589 support
This patch adds support for the Linear Technology LTC3589, LTC3589-1,
and LTC3589-2 8-output I2C voltage regulator ICs.
Signed-off-by: Lucas Stach l.st...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v1:
- Changed vendor prefix to lltc
- Lucas added a .ramp_delay initial value for the ramping regulators
---
drivers/regulator/Kconfig | 6 +
drivers/regulator/Makefile | 1 +
drivers/regulator/ltc3589.c | 565
3 files changed, 572 insertions(+)
create mode 100644 drivers/regulator/ltc3589.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 903eb37..5599a61 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -265,6 +265,12 @@ config REGULATOR_LP8788
help
This driver supports LP8788 voltage regulator chip.
+config REGULATOR_LTC3589
+ bool LTC3589 8-output voltage regulator
+ help
+ This enables support for the LTC3589, LTC3589-1, and LTC3589-2
+ 8-output regulators controlled via I2C.
+
config REGULATOR_MAX14577
tristate Maxim 14577 regulator
depends on MFD_MAX14577
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 12ef277..16d429b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
+obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
obj-$(CONFIG_REGULATOR_MAX14577) += max14577.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
obj-$(CONFIG_REGULATOR_MAX8649)+= max8649.o
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
new file mode 100644
index 000..fef64ee
--- /dev/null
+++ b/drivers/regulator/ltc3589.c
@@ -0,0 +1,565 @@
+/*
+ * Linear Technology LTC3589,LTC3589-1 regulator support
+ *
+ * Copyright (c) 2014 Philipp Zabel p.za...@pengutronix.de, Pengutronix
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/of.h
+#include linux/regmap.h
+#include linux/regulator/driver.h
+#include linux/regulator/of_regulator.h
+
+#define DRIVER_NAMEltc3589
+
+#define LTC3589_IRQSTAT0x02
+#define LTC3589_SCR1 0x07
+#define LTC3589_OVEN 0x10
+#define LTC3589_SCR2 0x12
+#define LTC3589_PGSTAT 0x13
+#define LTC3589_VCCR 0x20
+#define LTC3589_CLIRQ 0x21
+#define LTC3589_B1DTV1 0x23
+#define LTC3589_B1DTV2 0x24
+#define LTC3589_VRRCR 0x25
+#define LTC3589_B2DTV1 0x26
+#define LTC3589_B2DTV2 0x27
+#define LTC3589_B3DTV1 0x29
+#define LTC3589_B3DTV2 0x2a
+#define LTC3589_L2DTV1 0x32
+#define LTC3589_L2DTV2 0x33
+
+#define LTC3589_IRQSTAT_PGOOD_TIMEOUT BIT(3)
+#define LTC3589_IRQSTAT_UNDERVOLT_WARN BIT(4)
+#define LTC3589_IRQSTAT_UNDERVOLT_FAULTBIT(5)
+#define LTC3589_IRQSTAT_THERMAL_WARN BIT(6)
+#define LTC3589_IRQSTAT_THERMAL_FAULT BIT(7)
+
+#define LTC3589_OVEN_SW1 BIT(0)
+#define LTC3589_OVEN_SW2 BIT(1)
+#define LTC3589_OVEN_SW3 BIT(2)
+#define LTC3589_OVEN_BB_OUTBIT(3)
+#define LTC3589_OVEN_LDO2 BIT(4)
+#define LTC3589_OVEN_LDO3 BIT(5)
+#define LTC3589_OVEN_LDO4 BIT(6)
+#define LTC3589_OVEN_SW_CTRL BIT(7)
+
+#define LTC3589_VCCR_SW1_GOBIT(0)
+#define LTC3589_VCCR_SW2_GOBIT(2)
+#define LTC3589_VCCR_SW3_GOBIT(4)
+#define LTC3589_VCCR_LDO2_GO BIT(6)
+
+enum ltc3589_variant {
+ LTC3589,
+ LTC3589_1,
+ LTC3589_2,
+};
+
+enum ltc3589_reg {
+ LTC3589_SW1,
+ LTC3589_SW2,
+ LTC3589_SW3,
+ LTC3589_BB_OUT,
+ LTC3589_LDO1,
+ LTC3589_LDO2,
+ LTC3589_LDO3,
+ LTC3589_LDO4,
+ LTC3589_NUM_REGULATORS,
+};
+
+struct ltc3589_regulator {
+ struct regulator_desc desc;
+
+ /* External feedback voltage divider */
+ unsigned int r1;
+ unsigned int r2;
+};
+
+struct ltc3589 {
+ struct regmap *regmap;
+ struct device *dev;
+ enum ltc3589_variant variant;
+ struct ltc3589_regulator regulator_descs[LTC3589_NUM_REGULATORS];
+ struct
Re: [PATCH 1/3] mmc: host: add slot argument to mmc_of_parse
Hi,
On 05/26/2014 05:09 PM, Ludovic Desroches wrote:
On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Some hosts manage several slots. In these case information such as the
bus width, chi detect and others are into the slot node. So we have to
/s/chi detect/chip detect
Will fix.
Tushar have suggested the rename mmc_of_parse_slot() instead of
__mmc_of_parse().
I'm not sure which name is better. How about?
If never mind, i will change to mmc_of_parse_slot(), then send patch-v2.
Best Regards,
Jaehoon Chung
parse child node. If not NULL, slot node will be used instead of the
device node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
drivers/mmc/core/host.c | 13 +
include/linux/mmc/host.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 95cceae..0f677b3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
#endif
/**
- * mmc_of_parse() - parse host's device-tree node
+ * __mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot : some device provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
-np = host-parent-of_node;
+if (slot)
+np = slot;
+else
+np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
@@ -459,7 +464,7 @@ out:
return ret;
}
-EXPORT_SYMBOL(mmc_of_parse);
+EXPORT_SYMBOL(__mmc_of_parse);
/**
* mmc_alloc_host - initialise the per-host structure.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424..c62af91 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct
device *);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-int mmc_of_parse(struct mmc_host *host);
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
+/*
+ * mmc_of_parse - parse host's device-tree node
+ * @host: host whose node should be parsed.
+ */
+static inline int mmc_of_parse(struct mmc_host *host)
+{
+return __mmc_of_parse(host, NULL);
+}
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] of: Add vendor prefix for Linear Technology Corporation
Add Linear Technology Corporation to the list of device tree vendor prefixes. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- Changes since v1: - Changed vendor prefix to lltc --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0f01c9b..98e739f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -65,6 +65,7 @@ lantiqLantiq Semiconductor lg LG Corporation linux Linux-specific binding lsiLSI Corp. (LSI Logic) +lltc Linear Technology Corporation marvellMarvell Technology Group Ltd. maxim Maxim Integrated Products microchip Microchip Technology Inc. -- 2.0.0.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] export efi.flags to sysfs
For efi=old_map and any old_map quirks like SGI UV in current
tree kexec/kdump will fail because it depends on the new 1:1 mapping.
Thus export the mapping method to sysfs so kexec tools can switch
to original way to boot.
Since we have efi.flags for all efi facilities so let's just export the
efi.flags itself, it maybe useful for other arches and use cases.
Signed-off-by: Dave Young dyo...@redhat.com
---
drivers/firmware/efi/efi.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/firmware/efi/efi.c
===
--- linux-2.6.orig/drivers/firmware/efi/efi.c
+++ linux-2.6/drivers/firmware/efi/efi.c
@@ -86,16 +86,19 @@ static ssize_t name##_show(struct kobjec
EFI_ATTR_SHOW(fw_vendor);
EFI_ATTR_SHOW(runtime);
EFI_ATTR_SHOW(config_table);
+EFI_ATTR_SHOW(flags);
static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+static struct kobj_attribute efi_attr_flags = __ATTR_RO(flags);
static struct attribute *efi_subsys_attrs[] = {
efi_attr_systab.attr,
efi_attr_fw_vendor.attr,
efi_attr_runtime.attr,
efi_attr_config_table.attr,
+ efi_attr_flags.attr,
NULL,
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] regulator: s2mpa01: Use correct register for buck1 ramp delay
On 26 May 2014 13:56, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Fix the register for ramp delay of buck1 regulator. Buck1 and buck6 share the field (offset 4) in ramp delay register S2MPA01_REG_RAMP2. The driver used the same register and field for ramp delay of buck3 and buck1. This lead to updating of ramp delay of buck3 when setting buck1 and actually the ramp delay of buck1 was never set. Cc: sta...@vger.kernel.org Fixes: f18792714608 (regulator: Add support for S2MPA01 regulator) Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Sachin Kamat sachin.ka...@linaro.org -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mmc: host: add slot argument to mmc_of_parse
On 26 May 2014 10:38, Jaehoon Chung jh80.ch...@gmail.com wrote: Hi, On 05/26/2014 05:09 PM, Ludovic Desroches wrote: On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote: From: Ludovic Desroches ludovic.desroc...@atmel.com Some hosts manage several slots. In these case information such as the bus width, chi detect and others are into the slot node. So we have to /s/chi detect/chip detect Will fix. Tushar have suggested the rename mmc_of_parse_slot() instead of __mmc_of_parse(). I'm not sure which name is better. How about? If never mind, i will change to mmc_of_parse_slot(), then send patch-v2. I would prefer to keep it as is, but just because that's my taste. :-) Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode
On 5/23/2014 2:12 AM, Bin Liu wrote:
Hi George,
On Mon, May 19, 2014 at 11:32 PM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/19/2014 9:24 PM, Bin Liu wrote:
Hi,
On Mon, May 19, 2014 at 8:39 AM, George Cherian george.cher...@ti.com
wrote:
BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.
Handle babble condition iff MUSB is in HOST mode.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..eff3c5c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -849,7 +849,7 @@ b_host:
}
/* handle babble condition */
- if (int_usb MUSB_INTR_BABBLE)
+ if (int_usb MUSB_INTR_BABBLE is_host_active(musb))
schedule_work(musb-recover_work);
I guess my following comments are for Daniel's patch as while which
initially added the babble work.
Should this if statement be merged into the previous 'if(int_usb
MUSB_INTR_RESET)' one, which handles the same interrupt and already
handles host and device mode respectively.
Initially I too had the babble handling as part of 'if(int_usb
MUSB_INTR_RESET)'
one. But during my tests I hit a corner case where in we hit a BABBLE
condition
on disconnect. In such case the babble interrupt can be handled only if we
have a seperate
check, else its considered as a BUS RESET.
When all devices are disconnected MUSB_DEVCTL_HM = 0 and the code always
enter the
else path. In this path it treats the BABBLE as a BUS RESET.
The code flow is a bit confusing, two if() handle the same interrupt.
The second one implied using 'handled = IRQ_HANDLED;' from the first
one.
Also does the switch() in else{} in the first if() cause any side effect?
No it doesn't.
Since this babble handing is AM335x specific, how about handle it in
dsps_interrupt() in musb_dsps.c, which already has an entry for babble
interrupt? TI 3.2 kernel does this way.
That the reason we have platform specific callbacks added from the main
interrupt handler.
Regards,
-Bin.
Regards,
-Bin.
#if 0
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 03/16] kgr: initial code
On Tue, 20 May 2014, Jiri Slaby wrote: Yes, this is a problem I was thinking of in another context yesterday. Patching -read or any other file_openrations which hold state over user-kernel switches may be a potential threat like above. The same as in other implementations of live patching IMO. I put that on a TODO checklist for creating patches. This has to be investigated manually when creating a patch. Another thing that has to be handled very carefully is patching functions which are using self-modifying code (static keys), to make sure that the logic is not switched in the new function. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: mvebu: rename ARM_ERRATA_753970
ARM_ERRATA_753970 was renamed to PL310_ERRATA_753970 in v3.2, through commit fa0ce4035d48 (ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds). Two selects were added in v3.15-rc1 that still use the previous name. Rename these. Make these statements depend on CACHE_PL310, like all other selects of PL310_ERRATA_753970. That way it will only be selected if its dependency is met. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- I reported this before v3.15-rc1. I don't know whether any fixes are pending. None are in linux-next. And ignoring an errata were one apparently could be needed sounds, well, scary. Perhaps it is not. Anyhow, to make sure this gets fixed, hopefully before v3.15, I'm submitting this (untested!) patch. A related observation. There are three PL310 errata options: one depends on CACHE_PL310, three depend on CACHE_L2X0. The one depending on CACHE_PL310 is selected only if CACHE_PL310 is set. But the three depending on CACHE_L2X0 are selected a few times if CACHE_L2X0 is set, in other cases if CACHE_PL310 is set, and in some cases always. There may be good reasons for this, but it looks odd. I know nothing about the PL310 cache and its erratas, so I haven't looked into this any further. arch/arm/mach-mvebu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 3f73eecbcfb0..501d0f42e7b2 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -35,7 +35,7 @@ config MACH_ARMADA_370 config MACH_ARMADA_375 bool Marvell Armada 375 boards if ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 if CACHE_PL310 select ARM_GIC select ARMADA_375_CLK select CPU_V7 @@ -48,7 +48,7 @@ config MACH_ARMADA_375 config MACH_ARMADA_38X bool Marvell Armada 380/385 boards if ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 if CACHE_PL310 select ARM_GIC select ARMADA_38X_CLK select CPU_V7 -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] cfg80211: Add channel flags limiting availability to OCB mode only
On Mon, 2014-05-19 at 16:51 +0200, Johannes Berg wrote:
This patch is fine, but insufficient - you should also do something
with
the new flags?
That's definitely a good point. I think the biggest issue is that the
flags can't be checked only with the knowledge of the 'wiphy' but they
are related to the 'vif' type -- this prohibits checking in the
cfg80211_chandef_usable() (I assume).
Would the following be sufficient?
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -801,6 +801,10 @@ static int __ieee80211_vif_change_channel(struct
ieee80211_sub_if_data *sdata,
*changed |= BSS_CHANGED_BANDWIDTH;
}
+ if (sdata-vif.type == NL80211_IFTYPE_OCB
+ !(chandef-chan-flags IEEE80211_CHAN_OCB_ONLY))
+ return -EINVAL;
+
sdata-vif.bss_conf.chandef = *chandef;
ctx-conf.def = *chandef;
@@ -1049,6 +1053,12 @@ int ieee80211_vif_change_bandwidth(struct
ieee80211_sub_if_data *sdata,
goto out;
}
+ if (sdata-vif.type == NL80211_IFTYPE_OCB
+ !(chandef-chan-flags IEEE80211_CHAN_OCB_ONLY)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
if (chandef-width == NL80211_CHAN_WIDTH_20_NOHT ||
sdata-vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT) {
ret = -EINVAL;
--
Best regards;
Rostislav Lisovy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] bus: vexpress-config: Export devm_regmap_init_vexpress_config
Export this symbol to avoid build error when built as module. ERROR: devm_regmap_init_vexpress_config [drivers/regulator/vexpress.ko] undefined! Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/bus/vexpress-config.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c index 27a07dfcd626..2af2227874af 100644 --- a/drivers/bus/vexpress-config.c +++ b/drivers/bus/vexpress-config.c @@ -118,6 +118,7 @@ struct regmap *devm_regmap_init_vexpress_config(struct device *dev) return regmap; } +EXPORT_SYMBOL(devm_regmap_init_vexpress_config); struct device *vexpress_config_bridge_register(struct device *parent, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/13] mmc: mmci: Add Qualcomm Id to amba id table
Hi Srinivas,
+static struct variant_data variant_qcom = {
+ .fifosize = 16 * 4,
+ .fifohalfsize = 8 * 4,
+ .clkreg = MCI_CLK_ENABLE,
+ .datalength_bits= 24,
+ .blksz_datactrl4= true,
You get compile error here.
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mmc: host: add slot argument to mmc_of_parse
Hi, Ulf. On 05/26/2014 05:44 PM, Ulf Hansson wrote: On 26 May 2014 10:38, Jaehoon Chung jh80.ch...@gmail.com wrote: Hi, On 05/26/2014 05:09 PM, Ludovic Desroches wrote: On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote: From: Ludovic Desroches ludovic.desroc...@atmel.com Some hosts manage several slots. In these case information such as the bus width, chi detect and others are into the slot node. So we have to /s/chi detect/chip detect Will fix. Tushar have suggested the rename mmc_of_parse_slot() instead of __mmc_of_parse(). I'm not sure which name is better. How about? If never mind, i will change to mmc_of_parse_slot(), then send patch-v2. I would prefer to keep it as is, but just because that's my taste. :-) Ok. I think so. I want to merge this patch-set for fixing the dw-mmc problem, before release the 3.16. dw-mmc controller also used the slot concept, so some property didn't parse with mmc_of_parse(). Best Regards, Jaehoon Chung Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One question about this patch. Why don't you use the devices cgroup check if the root user in that namespace is allowed to use this device? This way you can be sure that the root in that namespace can not access devices to which the host system did not gave him access to. That might be possible, but I don't want to require something on the host to whitelist the device for the container. Then loop would need to automatically add the device to devices.allow, which doesn't seem desirable to me. But I'm not entirely opposed to the idea if others think this is a better way to go. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] sched: fix imbalance flag reset
On 05/26/2014 01:19 PM, Vincent Guittot wrote:
On 25 May 2014 12:33, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Hi Vincent,
On 05/23/2014 09:22 PM, Vincent Guittot wrote:
The imbalance flag can stay set whereas there is no imbalance.
Let assume that we have 3 tasks that run on a dual cores /dual cluster
system.
We will have some idle load balance which are triggered during tick.
Unfortunately, the tick is also used to queue background work so we can
reach
the situation where short work has been queued on a CPU which already runs a
task. The load balance will detect this imbalance (2 tasks on 1 CPU and an
idle
CPU) and will try to pull the waiting task on the idle CPU. The waiting
task is
a worker thread that is pinned on a CPU so an imbalance due to pinned task
is
detected and the imbalance flag is set.
Then, we will not be able to clear the flag because we have at most 1 task
on
each CPU but the imbalance flag will trig to useless active load balance
between the idle CPU and the busy CPU.
Why do we do active balancing today when there is at-most 1 task on the
busiest cpu? Shouldn't we be skipping load balancing altogether? If we
do active balancing when the number of tasks = 1, it will lead to a ping
pong right?
That's the purpose of the patch to prevent this useless active load
balance. When the imbalance flag is set, an active load balance is
triggered whatever the load balance is because of pinned tasks that
prevents a balance state.
No I mean this:
sched:Do not continue load balancing when the busiest cpu has one
running task
From: Preeti U Murthy pre...@linux.vnet.ibm.com
---
kernel/sched/fair.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c9617b7..b175333 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6626,6 +6626,8 @@ more_balance:
}
goto out_balanced;
}
+ } else {
+ goto out;
}
if (!ld_moved) {
}
Regards
Preeti U Murthy
Vincent
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/5] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()
For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue-wrp;
dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- udelay(100);
+ usleep_range(100, 200);
+ usb_phy_shutdown(musb-xceiv);
+ usleep_range(100, 200);
+ usb_phy_init(musb-xceiv);
+
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Atualize a sua conta Unicamp Webmail
Caros assinantes v?lidos Unicamp, Esta mensagem ? a partir da Unicamp Administrador E-mail Servi?o de TI para todos nossos subscribers.You conta de e-mail s?o fornecer-nos a seguir informa??es para revalidar sua conta devido a spam e atualiza??o Unicamp a vers?o de spam New m?s. Aviso: A sua conta Email Unicamp ser? expirado depois de uma semana, se voc? n?o revalidar ou Unicamp datam sua conta. Por favor, co-operar com conosco para que possamos atend?-lo melhor, em contato com o administrador! Nome de usu?rio: Senha: Confirme sua senha: E-mail alternativo: Obrigado. Unicamp E-mail do Administrador -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/5] usb: musb: core: Convert babble recover work to delayed work
During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.
To acheive this schedule a delayed work for babble recovery.
While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 15 ---
drivers/usb/musb/musb_core.h | 2 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0ad9551..c0ce09f 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
/* handle babble condition */
if (int_usb MUSB_INTR_BABBLE is_host_active(musb))
- schedule_work(musb-recover_work);
+ schedule_delayed_work(musb-recover_work,
+ msecs_to_jiffies(100));
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1751,16 +1752,16 @@ static void musb_irq_work(struct work_struct *data)
/* Recover from babble interrupt conditions */
static void musb_recover_work(struct work_struct *data)
{
- struct musb *musb = container_of(data, struct musb, recover_work);
+ struct musb *musb = container_of(data, struct musb, recover_work.work);
int status;
musb_platform_reset(musb);
usb_phy_vbus_off(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
usb_phy_vbus_on(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
/*
* When a babble condition occurs, the musb controller removes the
@@ -1943,7 +1944,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
- INIT_WORK(musb-recover_work, musb_recover_work);
+ INIT_DELAYED_WORK(musb-recover_work, musb_recover_work);
INIT_DELAYED_WORK(musb-deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(musb-finish_resume_work, musb_host_finish_resume);
@@ -2039,7 +2040,7 @@ fail4:
fail3:
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
if (musb-dma_controller)
@@ -2105,7 +2106,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb-dma_controller);
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index d155a15..9241025 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
- struct work_struct recover_work;
+ struct delayed_work recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/5] Add support for SW babble Control
Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. Patch 1 - Handle Babble only if MUSB is in HOST mode Patch 2 - Convert recover work to delayed work. Patch 3 - usb_phy_vbus_(off/_on) are NOPs for am335x PHY so use usb_phy(_shutdown/_init) in musb_platform_reset() Patch 4 - Add return value for musb_platform_reset() in prepration to support SW babble_ctrl Patch 5 - Add and Enable sw babble control for newer silicon v5 - v6 : Squash patch 5 and 6 form v5 to avoid build warnings. v4 - v5 : Added a debug print before resetting MUSB. changed a musb_readb to dsps_readb introduced in Patch#5 of v4. v3 - v4 : Fixes an issue in gagdet mode - BUS RESET should not be handled as a BABBLE. Added a check for the same.(Patch #1) Enable sw babble control properly (Patch #6) v2 - v3 : Modify musb_platform_reset() to return zero on success. George Cherian (5): usb: musb: core: Handle Babble condition only in HOST mode usb: musb: core: Convert babble recover work to delayed work usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: musb: core: Convert the musb_platform_reset to have a return value. usb: musb: dsps: Add the sw_babble_control() and Enable for newer silicon drivers/usb/musb/musb_core.c | 27 -- drivers/usb/musb/musb_core.h | 12 +++--- drivers/usb/musb/musb_dsps.c | 88 ++-- drivers/usb/musb/musb_regs.h | 7 4 files changed, 114 insertions(+), 20 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström: On 23.05.2014 17:40, Alex Courbot wrote: On 05/23/2014 06:59 PM, Lucas Stach wrote: So after checking with more knowledgeable people, it turns out this is the expected behavior on ARM and BAR regions should be mapped uncached on GK20A. All the more reasons to avoid using the BAR at all. This is actually specific to Tegra. You may want to make yourself aware of all the quirks required for sharing memory between the GPU and CPU on an ARM host. I think there are far more involved than what you see now and writing an replacement for TTM will not be an easy task. Doing away with the concept of two memory areas will not get you to a single unified address space. You would have to deal with things like not being able to change the caching state of pages in the systems lowmem yourself. You will still have to deal with remapping pages that aren't currently visible to the CPU (ok this is not an issue on Jetson right now as it only has 2GB of RAM), because it's in systems highmem, or even in a different LPAE area. You really want to be sure you are aware of all the consequences of this, before considering this task. Yep, that's why I am seeking advice here. My first hope is that with a few tweaks we will be able to keep using TTM and the current nouveau_bo implementation. But unless I missed something this is not going to be easy. We can also use something like the patch I originally sent to make it work, although not with good performance, on GK20A. Not very graceful, but it will allow applications to run. In the long run though, we will want to achieve better performance, and it seems like a BO implementation targeted at UMA devices would also be beneficial to quite a few desktop GPUs. So as tricky as it may be I'm interested in gathering thoughts and why not giving it a first try with GK20A, even if it imposes some limitations like having buffers in lowmem in a first time (we can probably live with this one for a short while, and 64 bits will also be coming to the rescue :)) I don't think lowmem or LPAE is any problem, if the memory manager is designed with that in mind. Vast majority of the buffers kernel allocates do not need to be touched in kernel space. Actually I can't think of any buffers that we allocate on behalf of user space that would need to be permanently mapped also to kernel. In case or relocs only push buffer needs to be temporarily mapped to kernel. Ultimately even relocs are not necessary if we expose GPU virtual addresses directly to user space. But that's another topic. Nouveau already exposes constant virtual addresses to userspace and skips the pushbuf patching when the presumed offset from userspace is the same as what the kernel thinks it should be. The problem with lowmem on ARM is that you can't unmap those pages from the kernel cached mapping. So if you alloc a page, give it to userspace and userspace decides to map the page WC you just produced a conflicting mapping, which may yield undefined results on ARMv7. You may think this is not a problem as you are not touching the kernel cached mapping, but in fact it is. The CPUs prefetcher can still access this mapping. Although it won't wander over a page boundary for automatic prefetching it may still do this when explicitly instructed to do so by code, which may happen for example if your page happens to be near a kernel list, where the list traversal code includes explicit prefetch instructions. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 5/5] usb: musb: dsps: Add the sw_babble_control() and Enable for newer silicon
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 89 +---
drivers/usb/musb/musb_regs.h | 7
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..01543a9 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+ bool sw_babble_enabled;
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val = ~(1 wrp-otg_disable);
dsps_writel(musb-ctrl_base, wrp-phy_utmi, val);
+ /*
+* Check whether the dsps version has babble control enabled.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+ val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
+ glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
+
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
return ret;
@@ -536,19 +550,82 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static bool sw_babble_control(struct musb *musb)
+{
+ u8 babble_ctl;
+ bool session_restart = false;
+
+ babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ dev_dbg(musb-controller, babble: MUSB_BABBLE_CTL value %x\n,
+ babble_ctl);
+ /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+ dev_dbg(musb-controller, STUCK_J is %s\n,
+ babble_ctl MUSB_BABBLE_STUCK_J ? set : reset);
+
+ if (babble_ctl MUSB_BABBLE_STUCK_J) {
+ int timeout = 10;
+
+ /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+ babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+ /* wait till line monitor flag cleared */
+ dev_dbg(musb-controller, Set TXIDLE, wait J to clear\n);
+ do {
+ babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ udelay(1);
+ } while ((babble_ctl MUSB_BABBLE_STUCK_J) timeout--);
+
+ /* check whether stuck_at_j bit cleared */
+ if (babble_ctl MUSB_BABBLE_STUCK_J) {
+ /*
+* real babble condition has occurred
+* restart the controller to start the
+* session again
+*/
+ dev_dbg(musb-controller, J not cleared, misc (%x)\n,
+ babble_ctl);
+ session_restart = true;
+ }
+ } else {
+ session_restart = true;
+ }
+
+ return session_restart;
+}
+
static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
+ int session_restart = 0;
- dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- usleep_range(100, 200);
- usb_phy_shutdown(musb-xceiv);
- usleep_range(100, 200);
- usb_phy_init(musb-xceiv);
+ if (glue-sw_babble_enabled)
+ session_restart = sw_babble_control(musb);
+ /*
+* In case of new silicon version babble condition can be recovered
+* without resetting the MUSB. But for older silicon versions, MUSB
+* reset is needed
+*/
+ if (session_restart || !glue-sw_babble_enabled) {
+ dev_info(musb-controller, Restarting MUSB to recover from
Babble\n);
+ dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
+
[PATCH v6 4/5] usb: musb: core: Convert the musb_platform_reset to have a return value.
Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for musb_platform_reset().
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 10 ++
drivers/usb/musb/musb_core.h | 10 ++
drivers/usb/musb/musb_dsps.c | 3 ++-
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c0ce09f..b841ee0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1753,9 +1753,11 @@ static void musb_irq_work(struct work_struct *data)
static void musb_recover_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, recover_work.work);
- int status;
+ int status, ret;
- musb_platform_reset(musb);
+ ret = musb_platform_reset(musb);
+ if (ret)
+ return;
usb_phy_vbus_off(musb-xceiv);
usleep_range(100, 200);
@@ -1764,8 +1766,8 @@ static void musb_recover_work(struct work_struct *data)
usleep_range(100, 200);
/*
-* When a babble condition occurs, the musb controller removes the
-* session bit and the endpoint config is lost.
+* When a babble condition occurs, the musb controller
+* removes the session bit and the endpoint config is lost.
*/
if (musb-dyn_fifo)
status = ep_config_from_table(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 9241025..414e57a 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
- void(*reset)(struct musb *musb);
+ int (*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -555,10 +555,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb-ops-reset)
- musb-ops-reset(musb);
+ if (!musb-ops-reset)
+ return -EINVAL;
+
+ return musb-ops-reset(musb);
}
static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..f6f3087 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ return 0;
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] of: Stop naming platform_device using dcr address
On Sat, May 24, 2014 at 5:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Fri, 2014-05-23 at 08:36 +0900, Grant Likely wrote:
There is now a way to ensure all platform devices get a unique name when
populated from the device tree, and the DCR_NATIVE code path is broken
anyway. PowerPC Cell (PS3) is the only platform that actually uses this
path. Most likely nobody will notice if it is killed. Remove the code
and associated ugly #ifdef.
The user-visible impact of this patch is that any DCR device on Cell
will get a new name in the /sys/devices hierarchy.
I don't understand. First DCR devices cover more than Cell (and not even
PS3). All 4xx embedded have some form of DCR based devices so I don't
know how much we use as platform.
What do you mean by the DCR_NATIVE code path is broken anyway ?
Take a look at the function. In the PPC_DCR_NATIVE path, the device
name is set using format d%x.%s, but the function doesn't return.
Instead, it falls through to the end of the function that sets the
device name again using %s.%d, so the first name never sticks.
The last time that code was touched was in 2010 by me when I moved it
out of arch/powerpc (94c0931983ee9, of: Merge of_device_alloc() and
of_device_make_bus_id()). It was already broken then. As far as I can
tell, it was broken as far back as 7eebde70, [POWERPC] Souped-up
of_platform_device support from 2006 which is when the code was
added. Did it ever work?
The only thing that selects the other option, PPC_DCR_MMIO is Cell in
arch/powerpc/platforms/cell/Kconfig. Every other DCR device is
PPC_DCR_NATIVE, all of which are broken.
Changing user visible platform device names has broken stuff in the
past, I'm not saying it is now but I'd like a better justification
for removing this.
The whole purpose of this function was to create unique names. The
previous patch solves that, so I'm not convinced that this extra code
path is still warranted. Given that nobody has complained about
PPC_DCR_NATIVE seeming never has worked, that path should be just
dropped outright since fixing it would be an user visible change
itself!
If you are really bothered about removing it on Cell, then I'll put it
back in. I just don't think it is worth it.
g.
Cheers,
Ben.
Signed-off-by: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring r...@kernel.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/dcr-mmio.h | 4
arch/powerpc/sysdev/dcr.c | 6 +++---
drivers/of/platform.c | 24
3 files changed, 3 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/include/asm/dcr-mmio.h
b/arch/powerpc/include/asm/dcr-mmio.h
index acd491dbd45a..93a68b28e695 100644
--- a/arch/powerpc/include/asm/dcr-mmio.h
+++ b/arch/powerpc/include/asm/dcr-mmio.h
@@ -51,10 +51,6 @@ static inline void dcr_write_mmio(dcr_host_mmio_t host,
out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
}
-extern u64 of_translate_dcr_address(struct device_node *dev,
- unsigned int dcr_n,
- unsigned int *stride);
-
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_MMIO_H */
diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index 1bd0eba4d355..e9056e438575 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -152,9 +152,9 @@ EXPORT_SYMBOL_GPL(dcr_resource_len);
#ifdef CONFIG_PPC_DCR_MMIO
-u64 of_translate_dcr_address(struct device_node *dev,
- unsigned int dcr_n,
- unsigned int *out_stride)
+static u64 of_translate_dcr_address(struct device_node *dev,
+ unsigned int dcr_n,
+ unsigned int *out_stride)
{
struct device_node *dp;
const u32 *p;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 95c133a0554b..52780a72d09d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -51,10 +51,6 @@ struct platform_device *of_find_device_by_node(struct
device_node *np)
}
EXPORT_SYMBOL(of_find_device_by_node);
-#if defined(CONFIG_PPC_DCR)
-#include asm/dcr.h
-#endif
-
#ifdef CONFIG_OF_ADDRESS
/*
* The following routines scan a subtree and registers a device for
@@ -78,26 +74,6 @@ void of_device_make_bus_id(struct device *dev)
const __be32 *reg;
u64 addr;
-#ifdef CONFIG_PPC_DCR
- /*
- * If it's a DCR based device, use 'd' for native DCRs
- * and 'D' for MMIO DCRs.
- */
- reg = of_get_property(node, dcr-reg, NULL);
- if (reg) {
-#ifdef CONFIG_PPC_DCR_NATIVE
- dev_set_name(dev, d%x.%s, *reg, node-name);
-#else /* CONFIG_PPC_DCR_NATIVE */
- u64 addr = of_translate_dcr_address(node, *reg, NULL);
- if (addr != OF_BAD_ADDR) {
- dev_set_name(dev, D%llx.%s,
-
[PATCH v6 1/5] usb: musb: core: Handle Babble condition only in HOST mode
BABBLE and RESET share the same interrupt. The interrupt is considered to be RESET if MUSB is in peripheral mode and as a BABBLE if MUSB is in HOST mode. Handle babble condition iff MUSB is in HOST mode. Signed-off-by: George Cherian george.cher...@ti.com --- drivers/usb/musb/musb_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 3c6043c..0ad9551 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -849,7 +849,7 @@ b_host: } /* handle babble condition */ - if (int_usb MUSB_INTR_BABBLE) + if (int_usb MUSB_INTR_BABBLE is_host_active(musb)) schedule_work(musb-recover_work); #if 0 -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/11] ARM: topology: use new cpu_power interface
On 05/26/2014 01:55 PM, Vincent Guittot wrote:
On 25 May 2014 15:22, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Hi Vincent,
Why do we have two interfaces arch_scale_freq_power() and
arch_scale_cpu_power()? Does it make sense to consolidate them now ?
Hi Preeti,
They don't have the same purpose. arch_scale_cpu_power set the max
capacity of your CPU whereas arch_scale_freq_power can be used to give
the current capacity. ARM platform were using arch_scale_freq_power
because it was the only one available for non SMT system but this
induces some misunderstanding and some limitation in the
characterization of a CPUs. This consolidation is a necessary step so
we can now have the max capacity of a CPU and let
arch_scale_freq_power for other purpose (or even remove it if
useless).
Ah ok! Thanks :) This was insightful :)
Regards
Preeti U Murthy
Regards,
Vincent
Regards
Preeti U Murthy
On 05/23/2014 09:22 PM, Vincent Guittot wrote:
Use the new arch_scale_cpu_power in order to reflect the original capacity
of
a CPU instead of arch_scale_freq_power which is more linked to a scaling of
the capacity linked to the frequency.
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
arch/arm/kernel/topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 71e1fec..6cc25a8 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -42,7 +42,7 @@
*/
static DEFINE_PER_CPU(unsigned long, cpu_scale);
-unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu)
+unsigned long arch_scale_cpu_power(struct sched_domain *sd, int cpu)
{
return per_cpu(cpu_scale, cpu);
}
@@ -166,7 +166,7 @@ static void update_cpu_power(unsigned int cpu)
set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
printk(KERN_INFO CPU%u: update cpu_power %lu\n,
- cpu, arch_scale_freq_power(NULL, cpu));
+ cpu, arch_scale_cpu_power(NULL, cpu));
}
#else
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/22] ARM: sunxi: Add earlyprintk support using R_UART (sun6i/sun8i)
On Mon, May 26, 2014 at 2:46 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Fri, May 23, 2014 at 03:51:22PM +0800, Chen-Yu Tsai wrote: sun6i/sun8i have a UART in the RTC block group, which can be used as an early console. This is most useful on sun8i as UART0 is muxed with MMC0, which is not available if we boot from MMC. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/Kconfig.debug | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index eab8ecb..9e22708 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -694,6 +694,14 @@ choice Say Y here if you want kernel low-level debugging support on Allwinner A1X based platforms on the UART1. + config DEBUG_SUNXI_R_UART + bool Kernel low-level debugging messages via sunXi R_UART + depends on ARCH_SUNXI It should rather depend on MACH_SUN8I. I assume no sun6i devices would use it, or have pads available for it? If so, then MACH_SUN8I makes sense. ChenYu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: Set hardirq tracing to on when idling
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote: From: Corey Minyard cminy...@mvista.com The CPU will go to idle with interrupts off, but the interrupts will wake up the idle. This was causing very long irqsoff trace values because, basically, the whole idle time was traces with irqs off, even though they weren't really off. Rework the idle code to turn hardirq tracing to on befor calling idle. Signed-off-by: Corey Minyard cminy...@mvista.com --- arch/arm/kernel/process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) I'm not sure this is correct for all ARM boards, but it fixes the issue for the Vexpress board I have. No more 4 second irqsoff times. If this patch is correct for ARM, I wonder if it should be done in architecture independent code instead. Do you see the same thing on x86? If not, do you know what's different? It seems like the right thing to do, I just don't understand why nobody hit this before. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] AMD IOMMUv2 Cleanups and Fixes
On Tue, May 20, 2014 at 11:18:21PM +0200, Joerg Roedel wrote: Joerg Roedel (5): iommu/amd: Don't access IOMMUv2 state_table directly iommu/amd: Convert IOMMUv2 state_table into state_list iommu/amd: Implement mmu_notifier_release call-back iommu/amd: Remove IOMMUv2 pasid_state_list iommu/amd: Handle parallel invalidate_range_start/end calls correctly Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/13] mmc: mmci: Qcomm: Add 3 clock cycle delay after register write
On 23 May 2014 14:51, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Most of the Qcomm SD card controller registers must be updated to the MCLK
domain so subsequent writes to registers will be ignored until 3 clock cycles
have passed.
This patch adds a 3 clock cycle delay required after writing to controller
registers on Qualcomm SOCs. Without this delay all the register writes are not
successful, resulting in not detecting cards. The write clock delay is
activated by setting up mclk_delayed_writes variable in variant data.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 881bb24..1385554 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -67,6 +67,8 @@ static unsigned int fmax = 515633;
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if busy detection on dat0 is supported
* @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
+ * @mclk_delayed_writes: enable delayed writes to ensure, subsequent updates
+ * are not ignored.
*/
struct variant_data {
unsigned intclkreg;
@@ -83,6 +85,7 @@ struct variant_data {
boolpwrreg_clkgate;
boolbusy_detect;
boolpwrreg_nopower;
+ boolmclk_delayed_writes;
};
static struct variant_data variant_arm = {
@@ -171,6 +174,12 @@ static struct variant_data variant_qcom = {
.datalength_bits= 24,
.blksz_datactrl4= true,
.pwrreg_powerup = MCI_PWR_UP,
+ /*
+* On QCom SD card controller, registers must be updated to the
+* MCLK domain so subsequent writes to this register will be ignored
+* for 3 clk cycles.
+*/
+ .mclk_delayed_writes= true,
};
static inline u32 mmci_readl(struct mmci_host *host, u32 off)
@@ -181,6 +190,9 @@ static inline u32 mmci_readl(struct mmci_host *host, u32
off)
static inline void mmci_writel(struct mmci_host *host, u32 data, u32 off)
{
writel(data, host-base + off);
+
+ if (host-variant-mclk_delayed_writes)
+ udelay(DIV_ROUND_UP((3 * USEC_PER_SEC), host-mclk));
}
I am not sure I like this approach. For each and every writel
(including pio_writes) you will add a few cpu cycles, since you need
to check for mclk_delayed_writes no matter of variant.
How about, adding a new function pointer in the struct mmci_host, for
writel operations which you could set up in probe phase instead?
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] cfg80211: Add channel flags limiting availability to OCB mode only
On Mon, 2014-05-26 at 11:06 +0200, Rostislav Lisovy wrote: On Mon, 2014-05-19 at 16:51 +0200, Johannes Berg wrote: This patch is fine, but insufficient - you should also do something with the new flags? That's definitely a good point. I think the biggest issue is that the flags can't be checked only with the knowledge of the 'wiphy' but they are related to the 'vif' type -- this prohibits checking in the cfg80211_chandef_usable() (I assume). Would the following be sufficient? Well, you'll find that if you address my comments on the other patch, all of this discussion goes away easily. johannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
