* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: James Bottomley @ 2013-01-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F64AC1.3040304@codeaurora.org>
On Wed, 2013-01-16 at 12:07 +0530, Subhash Jadavani wrote:
> Now consider this call stack from MMC block driver (this is on the ARmv7
> based board):
> [ 98.918174] [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from
> [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
> [ 98.927819] [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from
> [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
> [ 98.937982] [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from
> [<c0017ff8>] (dma_map_sg+0x3c/0x114)
OK, so this is showing that ARM itself is making the assumption that the
pages are contiguous in the page offset map.
Fix this by doing the increment via the pfn, which will do the right
thing whatever the memory model.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
---
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..ab88c5b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
op(vaddr, len, dir);
}
offset = 0;
- page++;
+ page = pfn_to_page(page_to_pfn(page) + 1);
left -= len;
} while (left);
}
^ permalink raw reply related
* [PATCH V3] mmc: mmci: Fixup and cleanup code for DMA handling
From: Ulf Hansson @ 2013-01-16 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130113192428.GU23505@n2100.arm.linux.org.uk>
On 13 January 2013 20:24, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 07, 2013 at 03:58:27PM +0100, Ulf Hansson wrote:
>> @@ -374,19 +415,12 @@ static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
>> * contiguous buffers. On TX, we'll get a FIFO underrun error.
>> */
>> if (status & MCI_RXDATAAVLBLMASK) {
>> - dmaengine_terminate_all(chan);
>> - if (!data->error)
>> - data->error = -EIO;
>> - }
>> -
>> - if (data->flags & MMC_DATA_WRITE) {
>> - dir = DMA_TO_DEVICE;
>> - } else {
>> - dir = DMA_FROM_DEVICE;
>> + data->error = -EIO;
>> + mmci_dma_data_error(host);
>
> Please explain the change of behaviour here. Before your change, we _only_
> set data->error if the error is not set. Here, we overwrite the error code
> no matter what. What is the reasoning for that change?
>
> The reason the code is like it _was_ is so that any bytes remaining in the
> FIFO are _only_ reported as an error if there wasn't a preceding error.
> That is the behaviour I desired when I wrote this code.
Since we need to do dmaengine_terminate_all(chan), that will mean
another request could potentially already be prepared and thus it
could also be terminated.
Then by always reporting an error the async request handling in the
mmc protocol layer, can do proper error handling and clean up the
previously prepared request.
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 05/14] lib: Add I/O map cache implementation
From: Thierry Reding @ 2013-01-16 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110192417.GA18478@obsidianresearch.com>
On Thu, Jan 10, 2013 at 12:24:17PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 10, 2013 at 08:03:27PM +0100, Thierry Reding wrote:
>
> > > > You'd piece a mapping together, each bus requires 16 64k mappings, a
> > > > simple 2d array of busnr*16 of pointers would do the trick. A more
> > > > clever solution would be to allocate contiguous virtual memory and
> > > > split that up..
>
> > > Oh, I see. I'm not very familiar with the internals of remapping, so
> > > I'll need to do some more reading. Thanks for the hints.
> >
> > I forgot to ask. What's the advantage of having a contiguous virtual
> > memory area and splitting it up versus remapping each chunk separately?
>
> Not alot, really, but it saves you from the pointer array and
> associated overhead. IIRC it is fairly easy to do in the kernel.
>
> Arnd's version is good too, but you would be restricted to aligned
> powers of two for the bus number range in the DT, which is probably
> not that big a deal either?
I've been trying to make this work, but this implementation always
triggers a BUG_ON() in lib/ioremap.c, line 27:
27 BUG_ON(!pte_none(*pte));
which seems to indicate that the page is already mapped, right?
Below is the relevant code:
struct tegra_pcie_bus {
struct vm_struct *area;
struct list_head list;
unsigned int nr;
};
static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
unsigned int busnr)
{
unsigned long flags = VM_READ | VM_WRITE | VM_IO | VM_PFNMAP |
VM_DONTEXPAND | VM_DONTDUMP;
phys_addr_t cs = pcie->cs->start;
struct tegra_pcie_bus *bus;
struct vm_struct *vm;
unsigned int i;
int err;
bus = devm_kzalloc(pcie->dev, sizeof(*bus), GFP_KERNEL);
if (!bus)
return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&bus->list);
bus->nr = busnr;
bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
if (!bus->area) {
err = -ENOMEM;
goto free;
}
for (i = 0; i < 16; i++) {
unsigned long virt = (unsigned long)bus->area->addr +
i * SZ_64K;
phys_addr_t phys = cs + busnr * SZ_64K + i * SZ_1M;
err = ioremap_page_range(virt, virt + SZ_64K - 1, phys,
vm_get_page_prot(flags));
if (err < 0) {
dev_err(pcie->dev, "ioremap_page_range() failed: %d\n",
err);
goto unmap;
}
}
return bus;
unmap:
vunmap(bus->area->addr);
free_vm_area(bus->area);
free:
devm_kfree(pcie->dev, bus);
return ERR_PTR(err);
}
Anybody see what's wrong with that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130116/7985e0cb/attachment.sig>
^ permalink raw reply
* [PATCH 15/16] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
From: Santosh Shilimkar @ 2013-01-16 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116100321.GA2325@e102568-lin.cambridge.arm.com>
On Wednesday 16 January 2013 03:33 PM, Lorenzo Pieralisi wrote:
> On Wed, Jan 16, 2013 at 06:33:40AM +0000, Santosh Shilimkar wrote:
>> On Tuesday 15 January 2013 11:50 PM, Dave Martin wrote:
>>> On Tue, Jan 15, 2013 at 11:53:14AM +0530, Santosh Shilimkar wrote:
>>>> On Monday 14 January 2013 05:55 PM, Lorenzo Pieralisi wrote:
>>>>> On Sat, Jan 12, 2013 at 07:21:24AM +0000, Santosh Shilimkar wrote:
>>>>>> On Saturday 12 January 2013 12:58 AM, Nicolas Pitre wrote:
>>>>>>> On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
>>>>>>>
>>>>>>>> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
>>>>>>>>> From: Dave Martin <dave.martin@linaro.org>
>>>>>>>>>
>>>>>>>>> + /*
>>>>>>>>> + * Flush the local CPU cache.
>>>>>>>>> + *
>>>>>>>>> + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
>>>>>>>>> + * a preliminary flush here for those CPUs. At least, that's
>>>>>>>>> + * the theory -- without the extra flush, Linux explodes on
>>>>>>>>> + * RTSM (maybe not needed anymore, to be investigated).
>>>>>>>>> + */
>>>>>>>> This is expected if the entire code is not in one stack frame and the
>>>>>>>> additional flush is needed to avoid possible stack corruption. This
>>>>>>>> issue has been discussed in past on the list.
>>>>>>>
>>>>>>> I missed that. Do you have a reference or pointer handy?
>>>>>>>
>>>>>>> What is strange is that this is 100% reproducible on RTSM while this
>>>>>>> apparently is not an issue on real hardware so far.
>>>>>>>
>>>>>> I tried searching archives and realized the discussion was in private
>>>>>> email thread. There are some bits and pieces on list but not all the
>>>>>> information.
>>>>>>
>>>>>> The main issue RMK pointed out is- An additional L1 flush needed
>>>>>> to avoid the effective change of view of memory when the C bit is
>>>>>> turned off, and the cache is no longer searched for local CPU accesses.
>>>>>>
>>>>>> In your case dcscb_power_down() has updated the stack which can be hit
>>>>>> in cache line and hence cache is dirty now. Then cpu_proc_fin() clears
>>>>>> the C-bit and hence for sub sequent calls the L1 cache won't be
>>>>>> searched. You then call flush_cache_all() which again updates the
>>>>>> stack but avoids searching the L1 cache. So it overwrites previous
>>>>>> saved stack frame. This seems to be an issue in your case as well.
>>>>>
>>>>> On A15/A7 even with the C bit cleared the D-cache is searched, the
>>>>> situation above cannot happen and if it does we are facing a HW/model bug.
>>>>> If this code is run on A9 then we have a problem since there, when the C bit
>>>>> is cleared D-cache is not searched (and that's why the sequence above
>>>>> should be written in assembly with no data access whatsoever), but on
>>>>> A15/A7 we do not.
>>>>>
>>>> Good point. May be model has modeled A9 and not A15 but in either
>>>> case, lets be consistent for all ARMv7 machines at least to avoid
>>>> people debugging similar issues. Many machines share code for ARMv7
>>>> processors so the best things is to stick to the sequence which works
>>>> across all ARMv7 processors.
>>>
>>> Is it sufficient to clarify the comment to indicate that the code is
>>> not directly reusable for other CPU combinations?
>>>
>> Thats not what I mean. CPU power down sequence is as per the
>> ARM specs so there shouldn't be an issue in case people
>> find it useful for other purposes. Thats other topc though.
>
> If they run it on an A9 there is an issue and as hotplug code for
> vexpress proved, copy'n'paste is a real danger.
>
>>
>>> DCSCB is incredibly platform-specific, and we would not expect to
>>> see it in other platforms.
>
> Agreed, but it is also the first example of power API implementation.
> Stubbing out this code in an assembly file valid for all v7 implementations
> is simple, provided we consider that worthwhile. I do. Or at least I can
> write the sequence up in /Documentation, how it should be done to be generic
> and describe the pitfalls.
>
>>>
>>> Or do we consider the risk of people copying this code verbatim
>>> (including the "do not copy this code" comment) too high?
>>>
>> I am not sure what exactly you mean. We are discussing the sequence
>> here on the basis of additional L1 cache flush. As mentioned
>> clearly the documentation is the ARM ARM(which is generic for
>> all ARMv7) missing to capture the need of the power
>> down code and stack usage which at least creates an issue on
>> A9. Documenting that in code and mainly in ARM specs would avoid
>> any further confusions.
>
> Power down sequence is defined explicitly in A15 and A7 TRMs. I do not
> think they should write "do not use the stack or cacheable memory that
> can result in dirty lines" in betweeen the power down steps. Once you
> know the C bit behaviour coding follows. True, they might add this for
> A9, and I asked that, to no avail, for internal reasons.
>
Fair enough.
> Documenting it in the kernel won't hurt either. And to answer Dave, I
> think that copy'n'paste verbatim is a risk we should not run, unless we
> are willing to be on the lookout for bugs. I can write up some documentation
> that we can merge along with the power API.
>
+1
Regards,
Santosh
^ permalink raw reply
* [PATCH 15/16] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
From: Lorenzo Pieralisi @ 2013-01-16 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F649C4.70400@ti.com>
On Wed, Jan 16, 2013 at 06:33:40AM +0000, Santosh Shilimkar wrote:
> On Tuesday 15 January 2013 11:50 PM, Dave Martin wrote:
> > On Tue, Jan 15, 2013 at 11:53:14AM +0530, Santosh Shilimkar wrote:
> >> On Monday 14 January 2013 05:55 PM, Lorenzo Pieralisi wrote:
> >>> On Sat, Jan 12, 2013 at 07:21:24AM +0000, Santosh Shilimkar wrote:
> >>>> On Saturday 12 January 2013 12:58 AM, Nicolas Pitre wrote:
> >>>>> On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> >>>>>
> >>>>>> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> >>>>>>> From: Dave Martin <dave.martin@linaro.org>
> >>>>>>>
> >>>>>>> + /*
> >>>>>>> + * Flush the local CPU cache.
> >>>>>>> + *
> >>>>>>> + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> >>>>>>> + * a preliminary flush here for those CPUs. At least, that's
> >>>>>>> + * the theory -- without the extra flush, Linux explodes on
> >>>>>>> + * RTSM (maybe not needed anymore, to be investigated).
> >>>>>>> + */
> >>>>>> This is expected if the entire code is not in one stack frame and the
> >>>>>> additional flush is needed to avoid possible stack corruption. This
> >>>>>> issue has been discussed in past on the list.
> >>>>>
> >>>>> I missed that. Do you have a reference or pointer handy?
> >>>>>
> >>>>> What is strange is that this is 100% reproducible on RTSM while this
> >>>>> apparently is not an issue on real hardware so far.
> >>>>>
> >>>> I tried searching archives and realized the discussion was in private
> >>>> email thread. There are some bits and pieces on list but not all the
> >>>> information.
> >>>>
> >>>> The main issue RMK pointed out is- An additional L1 flush needed
> >>>> to avoid the effective change of view of memory when the C bit is
> >>>> turned off, and the cache is no longer searched for local CPU accesses.
> >>>>
> >>>> In your case dcscb_power_down() has updated the stack which can be hit
> >>>> in cache line and hence cache is dirty now. Then cpu_proc_fin() clears
> >>>> the C-bit and hence for sub sequent calls the L1 cache won't be
> >>>> searched. You then call flush_cache_all() which again updates the
> >>>> stack but avoids searching the L1 cache. So it overwrites previous
> >>>> saved stack frame. This seems to be an issue in your case as well.
> >>>
> >>> On A15/A7 even with the C bit cleared the D-cache is searched, the
> >>> situation above cannot happen and if it does we are facing a HW/model bug.
> >>> If this code is run on A9 then we have a problem since there, when the C bit
> >>> is cleared D-cache is not searched (and that's why the sequence above
> >>> should be written in assembly with no data access whatsoever), but on
> >>> A15/A7 we do not.
> >>>
> >> Good point. May be model has modeled A9 and not A15 but in either
> >> case, lets be consistent for all ARMv7 machines at least to avoid
> >> people debugging similar issues. Many machines share code for ARMv7
> >> processors so the best things is to stick to the sequence which works
> >> across all ARMv7 processors.
> >
> > Is it sufficient to clarify the comment to indicate that the code is
> > not directly reusable for other CPU combinations?
> >
> Thats not what I mean. CPU power down sequence is as per the
> ARM specs so there shouldn't be an issue in case people
> find it useful for other purposes. Thats other topc though.
If they run it on an A9 there is an issue and as hotplug code for
vexpress proved, copy'n'paste is a real danger.
>
> > DCSCB is incredibly platform-specific, and we would not expect to
> > see it in other platforms.
Agreed, but it is also the first example of power API implementation.
Stubbing out this code in an assembly file valid for all v7 implementations
is simple, provided we consider that worthwhile. I do. Or at least I can
write the sequence up in /Documentation, how it should be done to be generic
and describe the pitfalls.
> >
> > Or do we consider the risk of people copying this code verbatim
> > (including the "do not copy this code" comment) too high?
> >
> I am not sure what exactly you mean. We are discussing the sequence
> here on the basis of additional L1 cache flush. As mentioned
> clearly the documentation is the ARM ARM(which is generic for
> all ARMv7) missing to capture the need of the power
> down code and stack usage which at least creates an issue on
> A9. Documenting that in code and mainly in ARM specs would avoid
> any further confusions.
Power down sequence is defined explicitly in A15 and A7 TRMs. I do not
think they should write "do not use the stack or cacheable memory that
can result in dirty lines" in betweeen the power down steps. Once you
know the C bit behaviour coding follows. True, they might add this for
A9, and I asked that, to no avail, for internal reasons.
Documenting it in the kernel won't hurt either. And to answer Dave, I
think that copy'n'paste verbatim is a risk we should not run, unless we
are willing to be on the lookout for bugs. I can write up some documentation
that we can merge along with the power API.
Lorenzo
^ permalink raw reply
* [PATCH 2/4] clk: ux500: Ensure the FMSC clock is obtainable
From: Lee Jones @ 2013-01-16 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115235252.23734.21408@quantum>
On Tue, 15 Jan 2013, Mike Turquette wrote:
> Quoting Lee Jones (2012-12-19 09:19:45)
> > The FMSC clock is traditionally used for NAND flash devices when
> > used on the ux500 series platforms. This patch makes it searchable
> > during a clock-name search.
> >
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Mike Turquette <mturquette@linaro.org>
>
> Who do you want this series to go through?
To be honest I don't really mind. I can take them through the
arm-soc tree with "[1/4] ARM ...", but I still need an Ack from
the SMSC911x maintainer for "[4/4] ...", before I can do that.
Still waiting for that. :(
> > ---
> > drivers/clk/ux500/u8500_clk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
> > index 6b889a0..a601802 100644
> > --- a/drivers/clk/ux500/u8500_clk.c
> > +++ b/drivers/clk/ux500/u8500_clk.c
> > @@ -324,7 +324,7 @@ void u8500_clk_init(void)
> >
> > clk = clk_reg_prcc_pclk("p3_pclk0", "per3clk", U8500_CLKRST3_BASE,
> > BIT(0), 0);
> > - clk_register_clkdev(clk, NULL, "fsmc");
> > + clk_register_clkdev(clk, "fsmc", NULL);
> >
> > clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", U8500_CLKRST3_BASE,
> > BIT(1), 0);
> > --
> > 1.7.9.5
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/3] can: c_can: Enable clock before first use
From: AnilKumar, Chimata @ 2013-01-16 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F65ECF.6070802@st.com>
+Rafael +arm list
On Wed, Jan 16, 2013 at 13:33:27, Amit Virdi wrote:
> On 12/20/2012 7:37 PM, Marc Kleine-Budde wrote:
> > On 12/20/2012 11:05 AM, Amit Virdi wrote:
> >> Current implementation assumes clock to be always enabled. Instead,
> >> explicitly enable device clock before usage.
> >>
> >> Signed-off-by: Amit Virdi<amit.virdi@st.com>
> >> Reviewed-by: Shiraz Hashim<shiraz.hashim@st.com>
> >> ---
> >> drivers/net/can/c_can/c_can_platform.c | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
> >> index 6e8dc56..d0bd6e6 100644
> >> --- a/drivers/net/can/c_can/c_can_platform.c
> >> +++ b/drivers/net/can/c_can/c_can_platform.c
> >> @@ -194,6 +194,12 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
> >> goto exit;
> >> }
> >>
> >> + ret = clk_prepare_enable(clk);
> >> + if (ret) {
> >> + dev_err(&pdev->dev, "could not prepare CAN clock\n");
> >> + goto exit_no_clk_en;
> >> + }
> >> +
> >> /* get the platform data */
> >> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> irq = platform_get_irq(pdev, 0);
> >> @@ -295,6 +301,8 @@ exit_iounmap:
> >> exit_release_mem:
> >> release_mem_region(mem->start, resource_size(mem));
> >> exit_free_clk:
> >> + clk_disable_unprepare(clk);
> >> +exit_no_clk_en:
> >> clk_put(clk);
> >> exit:
> >> dev_err(&pdev->dev, "probe failed\n");
> >
> > Why do you have to enable the clock if the driver is loaded? What about
> > disabling the clock on driver unload. The clock should be enabled on
> > open and disabled on close if the network interface. If you need to
> > access the registers of your hardware, you should enable the clock
> > before accessing the regs and disable the clock when finished.
> >
>
> Okay, I would take care of it in V2.
Hi Amit,
As Marc said clock enable/disable should be in sync with open/
close functions. I think pm_runtime calls should take care of
clock control. In your case you have to create a wrapper which
exports runtime pm hooks, which should internally handle the
clock enable/disable.
If we add clock specific calls to the driver, then driver might
break on the platforms which has runtime pm implemented because
runtime pm support to the c_can driver is already added.
Rafael,
Do you have any suggestions here? Am I missing anything here?
Thanks & Regards
AnilKumar
^ permalink raw reply
* [PATCH 5/5] W1: Convert MXC onewire master to devm_ functions.
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094821.9660.18278.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
drivers/w1/masters/mxc_w1.c | 35 ++++++++---------------------------
1 files changed, 8 insertions(+), 27 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 7454938..5b0c700 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -123,28 +123,22 @@ static int mxc_w1_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl)) {
err = PTR_ERR(pinctrl);
dev_err(&pdev->dev, "failed to get default pinctrl: %d\n", err);
- goto failed_pin;
+ goto failed;
}
- mdev->clk = clk_get(&pdev->dev, NULL);
+ mdev->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(mdev->clk)) {
err = PTR_ERR(mdev->clk);
- goto failed_clk;
+ goto failed;
}
mdev->clkdiv = (clk_get_rate(mdev->clk) / 1000000) - 1;
- res = request_mem_region(res->start, resource_size(res),
- "mxc_w1");
- if (!res) {
- err = -EBUSY;
- goto failed_req;
- }
-
- mdev->regs = ioremap(res->start, resource_size(res));
+ mdev->regs = devm_request_and_ioremap(&pdev->dev, res);
if (!mdev->regs) {
dev_err(&pdev->dev, "Cannot map mxc_w1 registers\n");
- goto failed_ioremap;
+ err = -ENXIO;
+ goto failed;
}
clk_prepare_enable(mdev->clk);
@@ -157,19 +151,12 @@ static int mxc_w1_probe(struct platform_device *pdev)
err = w1_add_master_device(&mdev->bus_master);
if (err)
- goto failed_add;
+ goto failed;
platform_set_drvdata(pdev, mdev);
return 0;
-failed_add:
- iounmap(mdev->regs);
-failed_ioremap:
- release_mem_region(res->start, resource_size(res));
-failed_req:
- clk_put(mdev->clk);
-failed_pin:
-failed_clk:
+failed:
kfree(mdev);
return err;
}
@@ -180,16 +167,10 @@ failed_clk:
static int mxc_w1_remove(struct platform_device *pdev)
{
struct mxc_w1_device *mdev = platform_get_drvdata(pdev);
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
w1_remove_master_device(&mdev->bus_master);
- iounmap(mdev->regs);
- release_mem_region(res->start, resource_size(res));
clk_disable_unprepare(mdev->clk);
- clk_put(mdev->clk);
platform_set_drvdata(pdev, NULL);
^ permalink raw reply related
* [PATCH 4/5] W1: Add pinctrl support to MXC onewire master.
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094821.9660.18278.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
drivers/w1/masters/mxc_w1.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 949e566..7454938 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/pinctrl/consumer.h>
#include "../w1.h"
#include "../w1_int.h"
@@ -107,6 +108,7 @@ static int mxc_w1_probe(struct platform_device *pdev)
{
struct mxc_w1_device *mdev;
struct resource *res;
+ struct pinctrl *pinctrl;
int err = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -117,6 +119,13 @@ static int mxc_w1_probe(struct platform_device *pdev)
if (!mdev)
return -ENOMEM;
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ err = PTR_ERR(pinctrl);
+ dev_err(&pdev->dev, "failed to get default pinctrl: %d\n", err);
+ goto failed_pin;
+ }
+
mdev->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(mdev->clk)) {
err = PTR_ERR(mdev->clk);
@@ -159,6 +168,7 @@ failed_ioremap:
release_mem_region(res->start, resource_size(res));
failed_req:
clk_put(mdev->clk);
+failed_pin:
failed_clk:
kfree(mdev);
return err;
^ permalink raw reply related
* [PATCH 3/5] DTS: Add device tree entry for onewire master on i.MX53
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094821.9660.18278.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
arch/arm/boot/dts/imx53.dtsi | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index edc3f1e..00c957c 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -387,6 +387,14 @@
};
};
+ owire {
+ pinctrl_owire_1: owiregrp-1 {
+ fsl,pins = <
+ 1166 0x80000000 /* MX53_PAD_GPIO_18__OWIRE_LINE */
+ >;
+ };
+ };
+
uart1 {
pinctrl_uart1_1: uart1grp-1 {
fsl,pins = <
@@ -570,6 +578,13 @@
status = "disabled";
};
+ owire: owire@63fa4000 {
+ compatible = "fsl,imx53-owire", "fsl,imx21-owire";
+ reg = <0x63fa4000 0x4000>;
+ clocks = <&clks 159>;
+ status = "disabled";
+ };
+
ecspi2: ecspi at 63fac000 {
#address-cells = <1>;
#size-cells = <0>;
^ permalink raw reply related
* [PATCH 2/5] ARM: i.MX53: Add clocks for i.mx53 onewire master.
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094821.9660.18278.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
.../devicetree/bindings/clock/imx5-clock.txt | 1 +
arch/arm/mach-imx/clk-imx51-imx53.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 04ad478..2a0c904 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -171,6 +171,7 @@ clocks and IDs.
can_sel 156
can1_serial_gate 157
can1_ipg_gate 158
+ owire_gate 159
Examples (for mx53):
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..7ff293b 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -83,6 +83,7 @@ enum imx5_clks {
ssi2_root_gate, ssi3_root_gate, ssi_ext1_gate, ssi_ext2_gate,
epit1_ipg_gate, epit1_hf_gate, epit2_ipg_gate, epit2_hf_gate,
can_sel, can1_serial_gate, can1_ipg_gate,
+ owire_gate,
clk_max
};
@@ -233,12 +234,13 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
clk[epit1_hf_gate] = imx_clk_gate2("epit1_hf_gate", "per_root", MXC_CCM_CCGR2, 4);
clk[epit2_ipg_gate] = imx_clk_gate2("epit2_ipg_gate", "ipg", MXC_CCM_CCGR2, 6);
clk[epit2_hf_gate] = imx_clk_gate2("epit2_hf_gate", "per_root", MXC_CCM_CCGR2, 8);
+ clk[owire_gate] = imx_clk_gate2("owire_gate", "per_root", MXC_CCM_CCGR2, 22);
for (i = 0; i < ARRAY_SIZE(clk); i++)
if (IS_ERR(clk[i]))
pr_err("i.MX5 clk %d: register failed with %ld\n",
i, PTR_ERR(clk[i]));
-
+
clk_register_clkdev(clk[gpt_hf_gate], "per", "imx-gpt.0");
clk_register_clkdev(clk[gpt_ipg_gate], "ipg", "imx-gpt.0");
clk_register_clkdev(clk[uart1_per_gate], "per", "imx21-uart.0");
^ permalink raw reply related
* [PATCH 1/5] W1: Add device tree support to MXC onewire master.
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094821.9660.18278.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
drivers/w1/masters/mxc_w1.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 708a25f..949e566 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -186,9 +186,16 @@ static int mxc_w1_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id mxc_w1_dt_ids[] = {
+ { .compatible = "fsl,imx21-owire" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxc_w1_dt_ids);
+
static struct platform_driver mxc_w1_driver = {
.driver = {
- .name = "mxc_w1",
+ .name = "mxc_w1",
+ .of_match_table = mxc_w1_dt_ids,
},
.probe = mxc_w1_probe,
.remove = mxc_w1_remove,
^ permalink raw reply related
* [PATCH 0/5] W1: Support onewire master on i.MX53
From: Martin Fuzzey @ 2013-01-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
W1: Support onewire master on i.MX53
* Add device tree and pinctrl support to the MXC master driver
* Add i.MX53 clocks
* Add i.MX53 device tree entries
The final patch converts the driver to use devm_
^ permalink raw reply
* [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Russell King - ARM Linux @ 2013-01-16 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877gndzvi6.fsf@rustcorp.com.au>
On Wed, Jan 16, 2013 at 01:26:01PM +1030, Rusty Russell wrote:
> Christoffer Dall <c.dall@virtualopensystems.com> writes:
>
> > On Mon, Jan 14, 2013 at 11:24 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote:
> >>> + /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
> >>> + for (i = 0; i < sizeof(init->features)*8; i++) {
> >>> + if (init->features[i / 32] & (1 << (i % 32))) {
> >>
> >> Isn't this an open-coded version of test_bit() ?
> >
> > indeed, nicely spotted:
>
> BTW, I wrote it that was out of excessive paranoia: it's a userspace
> API, and test_bit() won't be right on 64 bit BE systems.
So why is this a concern for 32-bit systems (which are, by definition,
only in arch/arm) ?
^ permalink raw reply
* [PATCH 1/1] clk-divider: fix is_power_of_two()
From: James Hogan @ 2013-01-16 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116005639.8920.45989@quantum>
On 16/01/13 00:56, Mike Turquette wrote:
> Quoting Joe Perches (2013-01-15 10:31:05)
>> On Tue, 2013-01-15 at 10:28 +0000, James Hogan wrote:
>>> The macro is_power_of_two() in clk-divider.c was defined as !(i & ~i)
>>> which is always true. Correct it to !(i & (i - 1)).
>> []
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>> []
>>> @@ -29,8 +29,8 @@
>> []
>>> -#define div_mask(d) ((1 << (d->width)) - 1)
>>> -#define is_power_of_two(i) !(i & ~i)
>>> +#define div_mask(d) ((1 << ((d)->width)) - 1)
>>> +#define is_power_of_two(i) (!((i) & ((i) - 1)))
>>
>> Use is_power_of_2 in log2.h instead?
>
> Both are fine suggestions. How about I apply the below patch?
Looks good to me, thanks for taking care of the log.h change.
Cheers
James
> From 54c6c9e5f61693effbe6e4fb28ef9f2f9b3d7a23 Mon Sep 17 00:00:00 2001
> From: James Hogan <james.hogan@imgtec.com>
> Date: Tue, 15 Jan 2013 10:28:05 +0000
> Subject: [PATCH] clk-divider: fix macros
>
> The macro is_power_of_two() in clk-divider.c was defined as !(i & ~i)
> which is always true. Instead use is_power_of_2() from log2.h.
>
> Also add brackets around the macro arguments in div_mask to avoid any
> future operator precedence problems.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Joe Perches <joe@perches.com>
> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> [mturquette at linaro.org: use log2.h per Joe Perches; update changelog]
> ---
> drivers/clk/clk-divider.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index a9204c6..68b4021 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -16,6 +16,7 @@
> #include <linux/io.h>
> #include <linux/err.h>
> #include <linux/string.h>
> +#include <linux/log2.h>
>
> /*
> * DOC: basic adjustable divider clock that cannot gate
> @@ -29,8 +30,7 @@
>
> #define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
>
> -#define div_mask(d) ((1 << (d->width)) - 1)
> -#define is_power_of_two(i) !(i & ~i)
> +#define div_mask(d) ((1 << ((d)->width)) - 1)
>
> static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
> {
> @@ -137,7 +137,7 @@ static bool _is_valid_table_div(const struct clk_div_table *table,
> static bool _is_valid_div(struct clk_divider *divider, unsigned int div)
> {
> if (divider->flags & CLK_DIVIDER_POWER_OF_TWO)
> - return is_power_of_two(div);
> + return is_power_of_2(div);
> if (divider->table)
> return _is_valid_table_div(divider->table, div);
> return true;
>
^ permalink raw reply
* [PATCH V5 3/3] ARM: davinci: da850: add NAND driver DT entries
From: Kumar, Anil @ 2013-01-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358327261-9679-1-git-send-email-anilkumar.v@ti.com>
Add NAND driver DT node and related pinctrl DT data to export NAND
functionality on da850 evm.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
---
:100644 100644 087ba28... 98c1a48... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 160ebac... f014f7b... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts | 5 +++++
arch/arm/boot/dts/da850.dtsi | 30 ++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 087ba28..98c1a48 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -28,4 +28,9 @@
status = "okay";
};
};
+ nand_cs3 at 62000000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_cs3_pins>;
+ };
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 160ebac..f014f7b 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -38,6 +38,23 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0xffffffff>;
status = "disabled";
+
+ nand_cs3_pins: pinmux_nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_OE, EMA_WE */
+ 0x1c 0x00110000 0x00ff0000
+ /* EMA_CS[4],EMA_CS[3]*/
+ 0x1c 0x00000110 0x00000ff0
+ /*
+ * EMA_D[0], EMA_D[1], EMA_D[2],
+ * EMA_D[3], EMA_D[4], EMA_D[5],
+ * EMA_D[6], EMA_D[7]
+ */
+ 0x24 0x11111111 0xffffffff
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x01100000 0x0ff00000
+ >;
+ };
};
serial0: serial at 1c42000 {
compatible = "ns16550a";
@@ -67,4 +84,17 @@
status = "disabled";
};
};
+ nand_cs3 at 62000000 {
+ compatible = "ti,davinci-nand";
+ reg = <0x62000000 0x807ff
+ 0x68000000 0x8000>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+ status = "disabled";
+ };
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 2/3] ARM: davinci: da8xx defconfig: enable pinctrl config option
From: Kumar, Anil @ 2013-01-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358327261-9679-1-git-send-email-anilkumar.v@ti.com>
Enable pinctrl related config option in da8xx_omapl_defconfig
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
---
:100644 100644 f292239... 0892db4... M arch/arm/configs/da8xx_omapl_defconfig
arch/arm/configs/da8xx_omapl_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig
index f292239..0892db4 100644
--- a/arch/arm/configs/da8xx_omapl_defconfig
+++ b/arch/arm/configs/da8xx_omapl_defconfig
@@ -81,6 +81,7 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DAVINCI=y
+CONFIG_PINCTRL_SINGLE=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_REGULATOR=y
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 1/3] ARM: davinci: da850: add pinctrl driver DT entries
From: Kumar, Anil @ 2013-01-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358327261-9679-1-git-send-email-anilkumar.v@ti.com>
For DT, DaVinci platform can use pinctrl-single driver for handling
padconf registers.
Enable PINCTRL Kconfig for MACH_DA8XX_DT platform. Add required
pinctrl DT entries in da850 dts file.
Test procedure
1)Populate DT file with NAND node information.
2)Populate board DT file with pinmux information for NAND.
3)Boot and confirm NAND is detected by the kernel.
4)cat /proc/mtd to show partitions.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
---
Cosmetic changes for pmx_core: pinmux at 1c14120 DT node
:100644 100644 37dc5a3... 087ba28... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 fbada87... 160ebac... M arch/arm/boot/dts/da850.dtsi
:100644 100644 0153950... a075b3e... M arch/arm/mach-davinci/Kconfig
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
arch/arm/mach-davinci/Kconfig | 1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..087ba28 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -15,6 +15,9 @@
model = "DA850/AM1808/OMAP-L138 EVM";
soc {
+ pmx_core: pinmux at 1c14120 {
+ status = "okay";
+ };
serial0: serial at 1c42000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index fbada87..160ebac 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -29,6 +29,16 @@
#size-cells = <1>;
ranges = <0x0 0x01c00000 0x400000>;
+ pmx_core: pinmux at 1c14120 {
+ compatible = "pinctrl-single";
+ reg = <0x14120 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xffffffff>;
+ status = "disabled";
+ };
serial0: serial at 1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0153950..a075b3e 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -62,6 +62,7 @@ config MACH_DA8XX_DT
bool "Support DA8XX platforms using device tree"
default y
depends on ARCH_DAVINCI_DA8XX
+ select PINCTRL
help
Say y here to include support for TI DaVinci DA850 based using
Flattened Device Tree. More information at Documentation/devicetree
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 0/3] ARM: davinci: da850: add pinctrl support
From: Kumar, Anil @ 2013-01-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
This set of patches adds:
* Add pinctrl-single for handling Padconf registers.
* Add NAND node to export NAND functionality on da850 EVM.
* Add NAND pinctrl node to do pin mux according to pinctrl-single driver.
This series applies on top of tag next-20130107 git tree
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
and the following patch
-drivers/pinctrl: grab default handles from device core
https://patchwork.kernel.org/patch/1862231/
This series is tested on da850 EVM.
Changes since V4:
-Cosmetic changes.
Changes since V3:
-Move NAND related pinctrl DT data into the da850.dtsi file so it can
be reused.
Changes since V2:
-Move NAND pins configuration into the nand_cs3 DT node to avoid pins
configuration if it is not probed.
Changes since V1:
-Remove the binding documentation as already documented as part of
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
-Enable PINCTRL Kconfig for MACH_DA8XX_DT platform only.
-Fix the pinctrl driver node unit-address.
-Make separate patch for da8xx_omapl_defconfig changes.
Kumar, Anil (3):
ARM: davinci: da850: add pinctrl driver DT entries
ARM: davinci: da8xx defconfig: enable pinctrl config option
ARM: davinci: da850: add NAND driver DT entries
arch/arm/boot/dts/da850-evm.dts | 8 ++++++
arch/arm/boot/dts/da850.dtsi | 40 ++++++++++++++++++++++++++++++++
arch/arm/configs/da8xx_omapl_defconfig | 1 +
arch/arm/mach-davinci/Kconfig | 1 +
4 files changed, 50 insertions(+), 0 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH v3 3/3] usb: chipidea: imx: Add system suspend/resume API
From: Peter Chen @ 2013-01-16 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358326745-25018-1-git-send-email-peter.chen@freescale.com>
During the system suspend/resume procedure, the USB also
needs to go suspend/resume procedure, this patch adds
related APIs. It is tested at i.mx6q sabrelite. Meanwhile,
it fixes the bug that the USB will out of work after
system suspend/resume.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/chipidea/bits.h | 1 +
drivers/usb/chipidea/ci13xxx_imx.c | 61 ++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ba9c6ef..d1467bb 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -47,6 +47,7 @@
#define PORTSC_FPR BIT(6)
#define PORTSC_SUSP BIT(7)
#define PORTSC_HSP BIT(9)
+#define PORTSC_PHCD BIT(23) /* phy suspend mode */
#define PORTSC_PTC (0x0FUL << 16)
/* DEVLC */
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c b/drivers/usb/chipidea/ci13xxx_imx.c
index 342eab0..dd257b1 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -25,6 +25,7 @@
#include <linux/mfd/syscon.h>
#include "ci.h"
+#include "bits.h"
#include "ci13xxx_imx.h"
#define pdev_to_phy(pdev) \
@@ -321,6 +322,63 @@ static int ci13xxx_imx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int ci13xxx_imx_suspend(struct device *dev)
+{
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data->ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 1);
+
+ if (data->phy)
+ usb_phy_set_suspend(data->phy, 1);
+
+ clk_disable_unprepare(data->clk);
+
+ return 0;
+}
+
+static int ci13xxx_imx_resume(struct device *dev)
+{
+ int ret;
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data->ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ ret = clk_prepare_enable(data->clk);
+ if (ret) {
+ dev_err(dev,
+ "Failed to prepare or enable clock, err=%d\n", ret);
+ return ret;
+ }
+
+ if (hw_read(ci, OP_PORTSC, PORTSC_PHCD)) {
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 0);
+ /* Some clks sync between Controller and USB PHY */
+ mdelay(1);
+ }
+
+ if (data->phy)
+ usb_phy_set_suspend(data->phy, 0);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ci13xxx_imx_pm_ops = {
+ .suspend = ci13xxx_imx_suspend,
+ .resume = ci13xxx_imx_resume,
+};
+#endif
+
static const struct of_device_id ci13xxx_imx_dt_ids[] = {
{ .compatible = "fsl,imx27-usb", },
{ /* sentinel */ }
@@ -334,6 +392,9 @@ static struct platform_driver ci13xxx_imx_driver = {
.name = "imx_usb",
.owner = THIS_MODULE,
.of_match_table = ci13xxx_imx_dt_ids,
+#ifdef CONFIG_PM
+ .pm = &ci13xxx_imx_pm_ops,
+#endif
},
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/3] usb: mxs-phy: add set_suspend API
From: Peter Chen @ 2013-01-16 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358326745-25018-1-git-send-email-peter.chen@freescale.com>
It needs to call set_suspend during USB suspend/resume
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/otg/mxs-phy.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 7630272..5158332 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -76,6 +76,25 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
clk_disable_unprepare(mxs_phy->clk);
}
+static int mxs_phy_suspend(struct usb_phy *x, int suspend)
+{
+ struct mxs_phy *mxs_phy = to_mxs_phy(x);
+
+ if (suspend) {
+ writel_relaxed(0xffffffff, x->io_priv + HW_USBPHY_PWD);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x->io_priv + HW_USBPHY_CTRL_SET);
+ clk_disable_unprepare(mxs_phy->clk);
+ } else {
+ clk_prepare_enable(mxs_phy->clk);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x->io_priv + HW_USBPHY_CTRL_CLR);
+ writel_relaxed(0, x->io_priv + HW_USBPHY_PWD);
+ }
+
+ return 0;
+}
+
static int mxs_phy_on_connect(struct usb_phy *phy,
enum usb_device_speed speed)
{
@@ -137,6 +156,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
mxs_phy->phy.label = DRIVER_NAME;
mxs_phy->phy.init = mxs_phy_init;
mxs_phy->phy.shutdown = mxs_phy_shutdown;
+ mxs_phy->phy.set_suspend = mxs_phy_suspend;
mxs_phy->phy.notify_connect = mxs_phy_on_connect;
mxs_phy->phy.notify_disconnect = mxs_phy_on_disconnect;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 1/3] ARM i.MX6: change mxs usbphy clock usage
From: Peter Chen @ 2013-01-16 8:59 UTC (permalink / raw)
To: linux-arm-kernel
This mxs usbphy is only needs to be on after system boots
up, and software never needs to control it anymore.
Meanwhile, usbphy's parent needs to be notified if usb
is suspend or not. So we design below mxs usbphy usage:
- usbphy1_gate and usbphy2_gate:
Their parents are dummy clock, we only needs to enable
it after system boots up.
- usbphy1 and usbphy2
Usage reserved bit for this clock, in that case, the refcount
will be updated, but without hardware changing.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
Changes for v3:
- Add new clk for usbphy clk gate which is only used
at system boots up process.
Changes for v2:
- Use reserved bit for usb phy clk control
arch/arm/mach-imx/clk-imx6q.c | 26 ++++++++++++++++++++++----
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 7f2c10c..ccb24cf 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -154,8 +154,8 @@ enum mx6q_clks {
usdhc4, vdo_axi, vpu_axi, cko1, pll1_sys, pll2_bus, pll3_usb_otg,
pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
- sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
- clk_max
+ sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
+ usbphy2_gate, clk_max
};
static struct clk *clk[clk_max];
@@ -208,8 +208,21 @@ int __init mx6q_clocks_init(void)
clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_usb_host","osc", base + 0x20, 0x3);
clk[pll8_mlb] = imx_clk_pllv3(IMX_PLLV3_MLB, "pll8_mlb", "osc", base + 0xd0, 0x0);
- clk[usbphy1] = imx_clk_gate("usbphy1", "pll3_usb_otg", base + 0x10, 6);
- clk[usbphy2] = imx_clk_gate("usbphy2", "pll7_usb_host", base + 0x20, 6);
+ /*
+ * Bit 20 is the reserved and read-only bit, we do this only for:
+ * - Do nothing for usbphy clk_enable/disable
+ * - Keep refcount when do usbphy clk_enable/disable, in that case,
+ * the clk framework may need to enable/disable usbphy's parent
+ */
+ clk[usbphy1] = imx_clk_gate("usbphy1", "pll3_usb_otg", base + 0x10, 20);
+ clk[usbphy2] = imx_clk_gate("usbphy2", "pll7_usb_host", base + 0x20, 20);
+
+ /*
+ * usbphy*_gate needs to be on after system boots up, and software
+ * never needs to control it anymore.
+ */
+ clk[usbphy1_gate] = imx_clk_gate("usbphy1_gate", "dummy", base + 0x10, 6);
+ clk[usbphy2_gate] = imx_clk_gate("usbphy2_gate", "dummy", base + 0x20, 6);
clk[sata_ref] = imx_clk_fixed_factor("sata_ref", "pll6_enet", 1, 5);
clk[pcie_ref] = imx_clk_fixed_factor("pcie_ref", "pll6_enet", 1, 4);
@@ -436,6 +449,11 @@ int __init mx6q_clocks_init(void)
for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
clk_prepare_enable(clk[clks_init_on[i]]);
+ if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
+ clk_prepare_enable(clk[usbphy1_gate]);
+ clk_prepare_enable(clk[usbphy2_gate]);
+ }
+
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
base = of_iomap(np, 0);
WARN_ON(!base);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-16 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F61D86.4020801@web.de>
On 16.01.2013 04:24, Soeren Moch wrote:
> On 16.01.2013 03:40, Jason Cooper wrote:
>> Soeren,
>>
>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>>> If my understanding is correct, one of the drivers (most likely one)
>>>>> either asks for too small of a dma buffer, or is not properly
>>>>> deallocating blocks from the per-device pool. Either case leads to
>>>>> exhaustion, and falling back to the atomic pool. Which subsequently
>>>>> gets wiped out as well.
>>>>
>>>> If my hunch is right, could you please try each of the three dvb
>>>> drivers
>>>> in turn and see which one (or more than one) causes the error?
>>>
>>> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
>>> demodulator, and dib0700 usb bridge plus dib7000p demod.
>>>
>>> I would bet for em28xx causing the error, but this is not thoroughly
>>> tested. Unfortunately testing with removed sticks is not easy, because
>>> this is a production system and disabling some services for the long
>>> time we need to trigger this error will certainly result in unhappy
>>> users.
>>
OK, I could trigger the error
ERROR: 1024 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!
only with em28xx sticks and sata, dib0700 sticks removed.
>> Just out of curiosity, what board is it?
>
> The kirkwood board? A modified Guruplug Server Plus.
em28xx sticks: "TerraTec Cinergy HTC Stick HD" and "PCTV Quatro Stick"
dib0700 sticks: "WinTV-NOVA-TD Stick"
>>
>>> I will see what I can do here. Is there an easy way to track the buffer
>>> usage without having to wait for complete exhaustion?
>>
>> DMA_API_DEBUG
>
> OK, maybe I can try this.
>>
>>> In linux-3.5.x there is no such problem. Can we use all available memory
>>> for dma buffers here on armv5 architectures, in contrast to newer
>>> kernels?
>>
>> Were the loads exactly the same when you tested 3.5.x?
>
> Exactly the same, yes.
>
>> I looked at the
>> changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
>> as sata_mv.
>>
>> The biggest thing I see is that all of the media drivers got shuffled
>> around into their own subdirectories after v3.5. 'git show -M 0c0d06c'
>> shows it was a clean copy of all the files.
>>
>> What would be most helpful is if you could do a git bisect between
>> v3.5.x (working) and the oldest version where you know it started
>> failing (v3.7.1 or earlier if you know it).
>>
> I did not bisect it, but Marek mentioned earlier that commit
> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> new code for dma allocations. This is probably the root cause for the
> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
I don't want to say that Mareks patch is wrong, probably it triggers a
bug somewhere else! (in em28xx?)
> I'm not very familiar with arm mm code, and from the patch itself I
> cannot understand what's different. Maybe CONFIG_CMA is default
> also for armv5 (not only v6) now? But I might be totally wrong here,
> maybe someone of the mm experts can explain the difference?
>
Regards,
Soeren
^ permalink raw reply
* [PATCH 0/3] clk: Provide option to unprepare unused clocks at late init
From: Ulf Hansson @ 2013-01-16 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCuDxszPZ-VYxhbNUSvyGM=rGw4h5Uy8LfqDcY0V-Dyg@mail.gmail.com>
On 20 December 2012 20:17, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 19, 2012 at 12:16 AM, Ulf Hansson
> <ulf.hansson@stericsson.com> wrote:
>
>> The disable_unused sequence executed at late init, is already handling the
>> fast unused ungated clocks to be gated. This patchset extends this sequence to
>> include the slow unused prepared clocks to be unprepared.
>>
>> The default behavior will not change in this patchset. To unprepare unused
>> clocks during the disable_unused sequence, the clk_hw needs to implement
>> the new optional callback, is_prepared.
>>
>> The motivation for this patchset is to save power. Clocks that is from
>> bootloaders prepared|enabled, but not used should be unprepared|disabled.
>
> This has a nice symmetrical touch to it and looks allright to me, so
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
Hi Mike,
Just a kind reminder on this, could this be merged for 3.9?
I have a patch for ux500 that make use of this new feature, so it is
of course fully tested.
My plan was to send this patch separately, but if you like to see a
"proof of concept" I can include it into this patchset!?
Thanks!
Ulf Hansson
^ permalink raw reply
* [PATCH 00/18] AB8500 battery management series upgrade
From: Lee Jones @ 2013-01-16 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116014812.GA27065@lizard.fhda.edu>
On Tue, 15 Jan 2013, Anton Vorontsov wrote:
> On Fri, Jan 11, 2013 at 01:12:48PM +0000, Lee Jones wrote:
> > Here we go again. This patches include your suggested fixups.
> >
> > Please find the next instalment of the AB8500 Power drivers upgrade.
> > A lot of work has taken place on the internal development track, but
> > little effort has gone into mainlining it. At last count there were
> > around 70+ patches which are in need of forward-porting, then
> > upstreaming. This patch-set aims to make a good start. :)
>
> All except 14/18 applied, thanks!
>
> Some general notes:
>
> - No need for the power: prefix in the subject, unless it is a core
> change;
> - Try be consistent on the capitalization (I tend to capitalize the first
> word, "driver: Fix something". But it's up to you, just be consistent).
> - Try keep the patches compilable. :)
> - ..and applicable to the battery tree.
>
> Thanks!
>
> Anton
>
> p.s. I'll push out the battery tree a bit later (in a couple of hours), so
> don't worry if the commits won't appear just now.
I'll keep 14/18 back until the next push and I'll try to be
diligent in adhering to your requests.
Very nice. Thanks Anton.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox