* [PATCH v6 05/12] iommu/exynos: support for device tree
From: Joerg Roedel @ 2013-02-01 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQjnOMav9A43m4=7=N9kzEHTHE_q_ygu8x6mzY6Cus=q0c06A@mail.gmail.com>
Cho,
On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote:
> On Tuesday, January 1, 2013, Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
> > Cc: devicetree-discuss at lists.ozlabs.org
Since patch 7 of this set is already merged, do you mind to re-post the
rest of this patch-set with the latest comments addressed? I can have a
look at it again then and consider it for 3.9.
Thanks,
Joerg
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BBD46.9020207@ti.com>
On Fri, Feb 01, 2013 at 06:34:06PM +0530, Santosh Shilimkar wrote:
> On Friday 01 February 2013 06:18 PM, Russell King - ARM Linux wrote:
>> On Fri, Feb 01, 2013 at 05:14:11PM +0530, Santosh Shilimkar wrote:
>>> On Friday 01 February 2013 05:02 PM, Russell King - ARM Linux wrote:
>>>> On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
>>>>> Now since we are moving the code under common place, probably we should
>>>>> update this a function a bit so that it invalidates the CPU cache till
>>>>> line of unification. Just to be consistent with other flush API.
>>>>
>>>> Hmm. Do you really want a CPU being brought up to do that to the PoU,
>>>> every time that it is brought up? I thought you wanted to get rid of
>>>> that kind of stuff from the hotplug paths so that a CPU being brought
>>>> up/taken down doesn't affect the caches for the other CPUs within the
>>>> inner sharable domain.
>>>>
>>> You are right. We already git rid of the flush of all cache levels
>>> in hotplug and wakeup paths and now it is restricted till the PoU.
>>>
>>> Assuming for the current v7 machines, PoU is L2, invalidating the cache
>>> *till* PoU means only CPU local cache. So the API will in a way
>>> invalidate only local cache.
>>
>> Err, you want to _invalidate_ the caches down to the point of I/D/TLB
>> unification? Are you really sure you want to do that on a system
>> here other CPUs are running?
>>
>> Even going down to the LoUIS, that point is the point at which the
>> _other_ CPUs may be sharing caches.
>>
>> And invalidating those caches while the other CPUs are running on
>> secondary CPU startup will be VERY VERY VERY bad.
>>
> Absolutly and my intention was never to invalidate all the cache
> levels. When I said lous, I mean till that point and not including
> that and next cache levels. May be my terminology isn't accurate.
Confused. Can't find the term "lous" in your previous mails. I'll
assume you mean LoUIS. I'm saying that's totally wrong because going
down to that point _includes_ the other CPUs in the system.
What we should be doing on secondary CPU bringup for CPUs where the
caches are in an unknown state is invalidating those caches which are
local to _that_ _CPU_ _only_. That is not "all cache levels down to
LoUIS".
Here's an example. CPU0-3 are in the inner sharable domain.
+----------+ +----------+ +----------+ +----------+
| CPU0 | | CPU1 | | CPU2 | | CPU3 |
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
+--v-+--v-+ +--v-+--v-+ +--v-+--v-+ +--v-+--v-+
|CL0I|CL0D| |CL0I|CL0D| |CL0I|CL0D| |CL0I|CL0D| <-- cache level 0
+----+----+ +----+----+ +----+----+ +----+----+
| | | | | | | |
| | +---+ +--+ | | | +------------------+
| | | | | +-------|--------------+ |
| | | +-------+ | | |
| | | | +-----------------|-----+ | |
| | | | +-----------+ | | |
| +---|--------|--------|--------+ | | |
+--v--------v--------v--------v--+ +--v--------v--------v--------v--+
| CL1I | | CL1D | level 1
+--------------------------------+ +--------------------------------+
| |
+----------------v-----------------------------------v---------------+
| CL2 | level 2
+--------------------------------------------------------------------+
Therefore, because the point of unification for the inner sharable domain
is defined as the point at which the I, D and TLB streams (TLB not shown)
are combined, this happens@CL2, and does *not* include CL2. CL2 is
where the two paths see the same data.
So, the LoUIS includes caches in level 0 and level 1.
However, CL1 _is_ shared between CPU0-3 - it is part of the inner sharable
domain. If you invalidate CL1, then you're destroying data held there by
the other CPUs. So, invalidating down to the LoUIS on secondary CPU
bringup is _wrong_.
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201124807.GK23505@n2100.arm.linux.org.uk>
On Friday 01 February 2013 06:18 PM, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 05:14:11PM +0530, Santosh Shilimkar wrote:
>> On Friday 01 February 2013 05:02 PM, Russell King - ARM Linux wrote:
>>> On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
>>>> Now since we are moving the code under common place, probably we should
>>>> update this a function a bit so that it invalidates the CPU cache till
>>>> line of unification. Just to be consistent with other flush API.
>>>
>>> Hmm. Do you really want a CPU being brought up to do that to the PoU,
>>> every time that it is brought up? I thought you wanted to get rid of
>>> that kind of stuff from the hotplug paths so that a CPU being brought
>>> up/taken down doesn't affect the caches for the other CPUs within the
>>> inner sharable domain.
>>>
>> You are right. We already git rid of the flush of all cache levels
>> in hotplug and wakeup paths and now it is restricted till the PoU.
>>
>> Assuming for the current v7 machines, PoU is L2, invalidating the cache
>> *till* PoU means only CPU local cache. So the API will in a way
>> invalidate only local cache.
>
> Err, you want to _invalidate_ the caches down to the point of I/D/TLB
> unification? Are you really sure you want to do that on a system
> here other CPUs are running?
>
> Even going down to the LoUIS, that point is the point at which the
> _other_ CPUs may be sharing caches.
>
> And invalidating those caches while the other CPUs are running on
> secondary CPU startup will be VERY VERY VERY bad.
>
Absolutly and my intention was never to invalidate all the cache
levels. When I said lous, I mean till that point and not including
that and next cache levels. May be my terminology isn't accurate.
Regards,
Santosh
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201121137.GC23869@e102568-lin.cambridge.arm.com>
On Fri, Feb 01, 2013 at 12:11:38PM +0000, Lorenzo Pieralisi wrote:
> Well, on latest processors (A15, A7) caches are invalidated on reset unless
> the chip is programmed to skip that on reset (ie L2 retained).
>
> But it makes sense, for sure it should not be called v7_invalidate_l1,
> but invalidate_louis, and instead of forcing level 0 we should be
> reading LoUIS and invalidate up to that level as we do in the clean and
> invalidate function.
No. Think about it. c7, c6, 2 _invalidates_ the cache. That means any
data contained within the cache is discarded. Data is not written back.
If you do this down to the LoUIS, that includes all cache levels in the
inner sharable domain. The inner sharable domain includes the other CPUs
in the system which may already be running (certainly the boot CPU will
be running).
Are you _really_ sure you want to be invalidating _valid_ data held in
caches in the inner sharable domain by other CPUs, rather than just the
cache associated with the CPU which is being brought online?
^ permalink raw reply
* [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
From: Padmavathi Venna @ 2013-02-01 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-1-git-send-email-padma.v@samsung.com>
This patch modify the filter function to filter the required channel
based on new filter params.
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
drivers/dma/pl330.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index ddf4dd0..14d84a4 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2392,15 +2392,12 @@ bool pl330_filter(struct dma_chan *chan, void *param)
#ifdef CONFIG_OF
if (chan->device->dev->of_node) {
- const __be32 *prop_value;
- phandle phandle;
- struct device_node *node;
-
- prop_value = ((struct property *)param)->value;
- phandle = be32_to_cpup(prop_value++);
- node = of_find_node_by_phandle(phandle);
- return ((chan->private == node) &&
- (chan->chan_id == be32_to_cpup(prop_value)));
+ struct dma_pl330_filter_args *fargs = param;
+
+ if (chan->device != &fargs->pdmac->ddma)
+ return false;
+
+ return (chan->chan_id == fargs->chan_id);
}
#endif
--
1.7.4.4
^ permalink raw reply related
* [PATCH V2 3/4] ARM: dts: Add #dma-cells for generic dma binding support
From: Padmavathi Venna @ 2013-02-01 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-1-git-send-email-padma.v@samsung.com>
This patch adds #dma-cells property to PL330 DMA controller
nodes for supporting generic dma dt bindings on samsung
exynos5250 platform.
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
.../devicetree/bindings/dma/arm-pl330.txt | 15 +++++++++++----
arch/arm/boot/dts/exynos5250.dtsi | 4 ++++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..1fdbff6 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -8,6 +8,8 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
+ - #dma-cells: must be <1>. used to represent the number of integer
+ cells in the dmas property of client device.
Optional properties:
- dma-coherent : Present if dma operations are coherent
@@ -18,16 +20,21 @@ Example:
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
+ #dma-cells = <1>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
-mem-to-dev) should specify the DMA channel numbers using a two-value pair
+mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
+ [property name] = <[dma channel name]>
where 'dma request id' is the dma request number which is connected
- to the client controller. The 'property name' is recommended to be
- of the form <name>-dma-channel.
+ to the client controller. The 'property name' 'dmas' and 'dma-names'
+ as required by the generic dma device tree binding helpers. The dma
+ names correspond 1:1 with the dma request ids in the dmas property.
- Example: tx-dma-channel = <&pdma0 12>;
+ Example: dmas = <&pdma0 12
+ &pdma1 11>;
+ dma-names = "tx", "rx";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index f50b4e8..724f5bd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -312,24 +312,28 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <0 34 0>;
+ #dma-cells = <1>;
};
pdma1: pdma at 121B0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <0 35 0>;
+ #dma-cells = <1>;
};
mdma0: mdma at 10800000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10800000 0x1000>;
interrupts = <0 33 0>;
+ #dma-cells = <1>;
};
mdma1: mdma at 11C10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <0 124 0>;
+ #dma-cells = <1>;
};
};
--
1.7.4.4
^ permalink raw reply related
* [PATCH V2 2/4] DMA: PL330: Register the DMA controller with the generic DMA helpers
From: Padmavathi Venna @ 2013-02-01 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-1-git-send-email-padma.v@samsung.com>
This patch registers the pl330 dma controller driver with the generic
device tree dma helper functions.
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
drivers/dma/pl330.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 6196cc0..ddf4dd0 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3004,6 +3004,14 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
pi->pcfg.num_peri, pi->pcfg.num_events);
+ ret = of_dma_controller_register(adev->dev.of_node,
+ of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(&adev->dev,
+ "unable to register DMA to the generic DT DMA helpers\n");
+ goto probe_err2;
+ }
+
return 0;
probe_err4:
@@ -3030,6 +3038,8 @@ static int pl330_remove(struct amba_device *adev)
if (!pdmac)
return 0;
+ of_dma_controller_free(adev->dev.of_node);
+
amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
--
1.7.4.4
^ permalink raw reply related
* [PATCH V2 1/4] DMA: PL330: Add xlate function
From: Padmavathi Venna @ 2013-02-01 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-1-git-send-email-padma.v@samsung.com>
Add xlate to translate the device-tree binding information into
the appropriate format. The filter function requires the dma
controller device and dma channel number as filter_params.
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
drivers/dma/pl330.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 80680ee..6196cc0 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -25,6 +25,7 @@
#include <linux/amba/pl330.h>
#include <linux/scatterlist.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include "dmaengine.h"
#define PL330_MAX_CHAN 8
@@ -606,6 +607,11 @@ struct dma_pl330_desc {
struct dma_pl330_chan *pchan;
};
+struct dma_pl330_filter_args {
+ struct dma_pl330_dmac *pdmac;
+ unsigned int chan_id;
+};
+
static inline void _callback(struct pl330_req *r, enum pl330_op_err err)
{
if (r && r->xfer_cb)
@@ -2352,6 +2358,31 @@ static void dma_pl330_rqcb(void *token, enum pl330_op_err err)
tasklet_schedule(&pch->task);
}
+struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec->args_count;
+ struct dma_pl330_dmac *pdmac = ofdma->of_dma_data;
+ struct dma_pl330_filter_args fargs;
+ dma_cap_mask_t cap;
+
+ if (!pdmac)
+ return NULL;
+
+ if (count != 1)
+ return NULL;
+
+ fargs.pdmac = pdmac;
+ fargs.chan_id = dma_spec->args[0];
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+ dma_cap_set(DMA_CYCLIC, cap);
+
+ return dma_request_channel(cap, pl330_filter, &fargs);
+}
+EXPORT_SYMBOL_GPL(of_dma_pl330_xlate);
+
bool pl330_filter(struct dma_chan *chan, void *param)
{
u8 *peri_id;
--
1.7.4.4
^ permalink raw reply related
* [PATCH V2 0/4] Add generic DMA DT binding support
From: Padmavathi Venna @ 2013-02-01 12:51 UTC (permalink / raw)
To: linux-arm-kernel
Changes since V1:
- Address the review comments by Arnd Bergmann as below
- Wording of the properties.
- Pass pdmac as third parameter to of_dma_controller_register
- Filter the dma channel based on channel number and dma_device
This patch set adds support for generic dma device tree bindings for
Samsung platforms and is dependent on the following patches from
Vinod Koul next branch
1)of: Add generic device tree DMA helpers
2)dmaengine: add helper function to request a slave DMA channel
This patch set is made based Mark Brown next branch
Padmavathi Venna (4):
DMA: PL330: Add xlate function
DMA: PL330: Register the DMA controller with the generic DMA helpers
ARM: dts: Add #dma-cells for generic dma binding support
DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
.../devicetree/bindings/dma/arm-pl330.txt | 15 ++++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
drivers/dma/pl330.c | 56 ++++++++++++++++---
3 files changed, 62 insertions(+), 13 deletions(-)
--
1.7.4.4
^ permalink raw reply
* [PATCH 4/9] USB: chipidea: add PTW and PTS handling
From: Alexander Shishkin @ 2013-02-01 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201090046.GA8056@pengutronix.de>
Michael Grzeschik <mgr@pengutronix.de> writes:
> On Fri, Feb 01, 2013 at 08:52:07AM +0100, Sascha Hauer wrote:
>> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>
>> This patch makes it possible to configure the PTW and PTS bits inside
>> the portsc register for host and device mode before the driver starts
>> and the phy can be addressed as hardware implementation is designed.
>>
>> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>> ---
>> .../devicetree/bindings/usb/ci13xxx-imx.txt | 5 +++
>> drivers/usb/chipidea/bits.h | 14 ++++++-
>> drivers/usb/chipidea/ci13xxx_imx.c | 3 ++
>> drivers/usb/chipidea/core.c | 39 ++++++++++++++++++++
>> include/linux/usb/chipidea.h | 1 +
>> 5 files changed, 61 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>> index 5778b9c..dd42ccd 100644
>> --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>> +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>> @@ -5,6 +5,11 @@ Required properties:
>> - reg: Should contain registers location and length
>> - interrupts: Should contain controller interrupt
>>
>> +Recommended properies:
>> +- phy_type: the type of the phy connected to the core. Should be one
>> + of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
>> + property the PORTSC register won't be touched
>> +
>> Optional properties:
>> - fsl,usbphy: phandler of usb phy that connects to the only one port
>> - fsl,usbmisc: phandler of non-core register device, with one argument
>> diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
>> index 050de85..d8ffc2f 100644
>> --- a/drivers/usb/chipidea/bits.h
>> +++ b/drivers/usb/chipidea/bits.h
>> @@ -48,10 +48,22 @@
>> #define PORTSC_SUSP BIT(7)
>> #define PORTSC_HSP BIT(9)
>> #define PORTSC_PTC (0x0FUL << 16)
>> +/* PTS and PTW for non lpm version only */
>> +#define PORTSC_PTS(d) ((((d) & 0x3) << 30) | (((d) & 0x4) ? BIT(25) : 0))
>> +#define PORTSC_PTW BIT(28)
>>
>> /* DEVLC */
>> #define DEVLC_PSPD (0x03UL << 25)
>> -#define DEVLC_PSPD_HS (0x02UL << 25)
>> +#define DEVLC_PSPD_HS (0x02UL << 25)
>> +#define DEVLC_PTW BIT(27)
>> +#define DEVLC_STS BIT(28)
>> +#define DEVLC_PTS(d) (((d) & 0x7) << 29)
>> +
>> +/* Encoding for DEVLC_PTS and PORTSC_PTS */
>> +#define PTS_UTMI 0
>> +#define PTS_ULPI 2
>> +#define PTS_SERIAL 3
>> +#define PTS_HSIC 4
>>
>> /* OTGSC */
>> #define OTGSC_IDPU BIT(5)
>> diff --git a/drivers/usb/chipidea/ci13xxx_imx.c b/drivers/usb/chipidea/ci13xxx_imx.c
>> index 69024e0..ebc1148 100644
>> --- a/drivers/usb/chipidea/ci13xxx_imx.c
>> +++ b/drivers/usb/chipidea/ci13xxx_imx.c
>> @@ -21,6 +21,7 @@
>> #include <linux/clk.h>
>> #include <linux/regulator/consumer.h>
>> #include <linux/pinctrl/consumer.h>
>> +#include <linux/usb/of.h>
>>
>> #include "ci.h"
>> #include "ci13xxx_imx.h"
>> @@ -112,6 +113,8 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
>> CI13XXX_PULLUP_ON_VBUS |
>> CI13XXX_DISABLE_STREAMING;
>>
>> + pdata->phy_mode = of_usb_get_phy_mode(pdev->dev.of_node);
>> +
>> data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> if (!data) {
>> dev_err(&pdev->dev, "Failed to allocate CI13xxx-IMX data!\n");
>> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
>> index 57cae1f..a3ec29d 100644
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -67,6 +67,8 @@
>> #include <linux/usb/gadget.h>
>> #include <linux/usb/otg.h>
>> #include <linux/usb/chipidea.h>
>> +#include <linux/usb/of.h>
>> +#include <linux/phy.h>
>>
>> #include "ci.h"
>> #include "udc.h"
>> @@ -211,6 +213,41 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem *base)
>> return 0;
>> }
>>
>> +static void hw_phymode_configure(struct ci13xxx *ci)
>> +{
>> + u32 portsc, lpm;
>> +
>> + switch (ci->platdata->phy_mode) {
>> + case USBPHY_INTERFACE_MODE_UTMI:
>> + portsc = PORTSC_PTS(PTS_UTMI);
>> + lpm = DEVLC_PTS(PTS_UTMI);
>> + break;
>> + case USBPHY_INTERFACE_MODE_UTMIW:
>> + portsc = PORTSC_PTS(PTS_UTMI) | PORTSC_PTW;
>> + lpm = DEVLC_PTS(PTS_UTMI) | DEVLC_PTW;
>> + break;
>> + case USBPHY_INTERFACE_MODE_ULPI:
>> + portsc = PORTSC_PTS(PTS_ULPI);
>> + lpm = DEVLC_PTS(PTS_ULPI);
>> + break;
>> + case USBPHY_INTERFACE_MODE_SERIAL:
>> + portsc = PORTSC_PTS(PTS_SERIAL);
>> + lpm = DEVLC_PTS(PTS_SERIAL);
>> + break;
>> + case USBPHY_INTERFACE_MODE_HSIC:
>> + portsc = PORTSC_PTS(PTS_HSIC);
>> + lpm = DEVLC_PTS(PTS_HSIC);
>> + break;
>> + default:
>> + return;
>> + }
>> +
>> + if (ci->hw_bank.lpm)
>> + hw_write(ci, OP_PORTSC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
> ^^^^^^^^^
>
> This is probably supposed to be OP_DEVLC.
Looks like that. I'd like to test this code on an LPM device first.
Can somebody with an imx test give a Tested-by?
Regards,
--
Alex
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BAA8B.1030506@ti.com>
On Fri, Feb 01, 2013 at 05:14:11PM +0530, Santosh Shilimkar wrote:
> On Friday 01 February 2013 05:02 PM, Russell King - ARM Linux wrote:
>> On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
>>> Now since we are moving the code under common place, probably we should
>>> update this a function a bit so that it invalidates the CPU cache till
>>> line of unification. Just to be consistent with other flush API.
>>
>> Hmm. Do you really want a CPU being brought up to do that to the PoU,
>> every time that it is brought up? I thought you wanted to get rid of
>> that kind of stuff from the hotplug paths so that a CPU being brought
>> up/taken down doesn't affect the caches for the other CPUs within the
>> inner sharable domain.
>>
> You are right. We already git rid of the flush of all cache levels
> in hotplug and wakeup paths and now it is restricted till the PoU.
>
> Assuming for the current v7 machines, PoU is L2, invalidating the cache
> *till* PoU means only CPU local cache. So the API will in a way
> invalidate only local cache.
Err, you want to _invalidate_ the caches down to the point of I/D/TLB
unification? Are you really sure you want to do that on a system
here other CPUs are running?
Even going down to the LoUIS, that point is the point at which the
_other_ CPUs may be sharing caches.
And invalidating those caches while the other CPUs are running on
secondary CPU startup will be VERY VERY VERY bad.
^ permalink raw reply
* [PATCH] USB chipidea i.MX: use framework phy handling
From: Peter Chen @ 2013-02-01 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201073614.GX1906@pengutronix.de>
On Fri, Feb 01, 2013 at 08:36:14AM +0100, Sascha Hauer wrote:
> On Thu, Jan 31, 2013 at 12:32:15PM +0100, Sascha Hauer wrote:
> > This series switches the mxs phy and the i.MX chipidea support
> > from homegrew phy support to use usb_add_phy_dev/devm_usb_get_phy_by_phandle.
> >
> > Based on
> >
> > [PATCH v2] Add USB of helpers and use them in the chipidea driver
> >
> > But I think this could also be applied separately if necessary.
>
> Kishon, Peter,
>
> Thanks for reviewing these, but I'm afraid I must send another iteration
> for these. These patches do not handle -EPROBE_DEFER correctly.
which patch you have added handle -EPROBE_DEFER at v3?
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH, RFC] default machine descriptor for multiplatform
From: Arnd Bergmann @ 2013-02-01 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BAB55.30603@ti.com>
On Friday 01 February 2013, Santosh Shilimkar wrote:
> This is indeed a nice update towards consolidation. Though
> on OMAP, we need to do some work to effectively get rid
> of machine, time and irq inits. Will add this task in my
> TODO queue.
There is no urgent need to get all board files to have empty
machine descriptors, I would not expect that to happen for
the more complex platforms like omap any time soon.
You currently use quite a number of callbacks:
DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
.reserve = omap_reserve,
.smp = smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
.init_early = omap5_init_early,
.init_irq = omap_gic_of_init,
.handle_irq = gic_handle_irq,
.init_machine = omap_generic_init,
.timer = &omap5_timer,
.dt_compat = omap5_boards_compat,
.restart = omap44xx_restart,
MACHINE_END
and I see nothing wrong with that. For simpler platforms that
after migrating out init_irq and init_timer have only one
or two callbacks left, it may be more interesting to actually
go all the way and remove all of them if possible.
Arnd
^ permalink raw reply
* [PATCH 5/9] USB chipidea: introduce dual role mode pdata flags
From: Peter Chen @ 2013-02-01 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359704911-8275-6-git-send-email-s.hauer@pengutronix.de>
On Fri, Feb 01, 2013 at 08:48:26AM +0100, Sascha Hauer wrote:
> Even if a chipidea core is otg capable the board may not. This allows
> to explicitly set the core to host/peripheral mode. Without these
> flags the driver falls back to the old behaviour.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/chipidea/core.c | 21 +++++++++++++++------
> include/linux/usb/chipidea.h | 2 +-
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index a3ec29d..b2dbf55 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -435,6 +435,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> struct resource *res;
> void __iomem *base;
> int ret;
> + int dr_mode;
why not using enum usb_dr_mode;
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201121137.GC23869@e102568-lin.cambridge.arm.com>
On Friday 01 February 2013 05:41 PM, Lorenzo Pieralisi wrote:
> On Fri, Feb 01, 2013 at 11:29:44AM +0000, Santosh Shilimkar wrote:
>> + Lorenzo,
>>
>> On Thursday 31 January 2013 10:35 PM, dinguyen at altera.com wrote:
>>> From: Dinh Nguyen <dinguyen@altera.com>
>>>
>>> mach-socfpga is another platform that needs to use
>>> v7_invalidate_l1 to bringup additional cores. There was a comment that
>>> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>>>
>>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
>>> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>>> Tested-by: Pavel Machek <pavel@denx.de>
>>> Reviewed-by: Pavel Machek <pavel@denx.de>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Cc: Sascha Hauer <kernel@pengutronix.de>
>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>>> ---
>>> arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
>>> arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
>>> arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
>>> arch/arm/mm/cache-v7.S | 46 ++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 46 insertions(+), 138 deletions(-)
>>>
>> [..]
>>
>>> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
>>> index 7539ec2..15451ee 100644
>>> --- a/arch/arm/mm/cache-v7.S
>>> +++ b/arch/arm/mm/cache-v7.S
>>> @@ -19,6 +19,52 @@
>>> #include "proc-macros.S"
>>>
>>> /*
>>> + * The secondary kernel init calls v7_flush_dcache_all before it enables
>>> + * the L1; however, the L1 comes out of reset in an undefined state, so
>>> + * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
>>> + * of cache lines with uninitialized data and uninitialized tags to get
>>> + * written out to memory, which does really unpleasant things to the main
>>> + * processor. We fix this by performing an invalidate, rather than a
>>> + * clean + invalidate, before jumping into the kernel.
>>> + *
>>> + * This function is cloned from arch/arm/mach-tegra/headsmp.S, and needs
>>> + * to be called for both secondary cores startup and primary core resume
>>> + * procedures.
>>> + */
>>> +ENTRY(v7_invalidate_l1)
>> Now since we are moving the code under common place, probably we should
>> update this a function a bit so that it invalidates the CPU cache till
>> line of unification. Just to be consistent with other flush API.
>>
>> Lorenzo,
>> Does that make sense ?
>
> Well, on latest processors (A15, A7) caches are invalidated on reset unless
> the chip is programmed to skip that on reset (ie L2 retained).
>
> But it makes sense, for sure it should not be called v7_invalidate_l1,
> but invalidate_louis, and instead of forcing level 0 we should be
> reading LoUIS and invalidate up to that level as we do in the clean and
> invalidate function.
>
That is exactly what I was thinking.
> Is it worth adding a v7 cache function where the only difference wrt the clean
> and invalidate operation is a coprocessor opcode ? Probably not IMHO, why add
> the set/way loop again ?
>
Probably same function can be re-used with the parameter passing to
differentiate the inv and flush.
> It is never called from C code, so I do not think there is a point in
> adding a C API either.
>
I agree. C API isn't needed.
Regards,
Santosh
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Peter Chen @ 2013-02-01 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201065833.GV1906@pengutronix.de>
On Fri, Feb 01, 2013 at 07:58:34AM +0100, Sascha Hauer wrote:
> On Fri, Feb 01, 2013 at 09:11:54AM +0800, Peter Chen wrote:
> > On Thu, Jan 31, 2013 at 11:29:13AM +0100, Sascha Hauer wrote:
> > > On Thu, Jan 31, 2013 at 10:05:44AM +0800, Peter Chen wrote:
> > > > On Wed, Jan 30, 2013 at 03:00:15PM +0100, Sascha Hauer wrote:
> > > > > On Wed, Jan 30, 2013 at 10:06:28AM +0800, Peter Chen wrote:
> > > > > > On Tue, Jan 29, 2013 at 01:55:04PM +0200, Alexander Shishkin wrote:
> > > > > > > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > > > > > >
> > > > > > > > From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > > > > >
> > > > > > > > This adds two little devicetree helper functions for determining the
> > > > > > > > dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> > > > > > > > the devicetree.
> > > > > > > >
> > > > > > > > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > > > > > Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > The properties and their values have been taken from the fsl-mph-dr driver.
> > > > > > > > This binding is also documented (though currently not used) for the tegra
> > > > > > > > ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> > > > > > > > This is a first attempt to parse these bindings at a common place so that
> > > > > > > > others can make use of it.
> > > > > > > >
> > > > > > > > Basically I want to know whether this binding is recommended for new drivers
> > > > > > > > since normally the devicetree uses '-' instead of '_', and maybe there are
> > > > > > > > other problems with it.
> > > > > > > >
> > > > > > > > I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> > > > > > > > driver also really handles a chipidea core.
> > > > > > >
> > > > > > > As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
> > > > > > > probably confirm.
> > > > > >
> > > > > > The fsl-mph-dr can't be used for chipdiea as it handles three platform
> > > > > > drivers for three roles (peripheral , host, otg). But chipidea only has
> > > > > > two platform drivers, one is the chipidea core, the other is related
> > > > > > controller wrapper.
> > > > >
> > > > > What do you mean by 'three platform drivers'? That's only how the driver
> > > > > is built, no? I was talking about the hardware the fsl-mph-dr driver
> > > > > handles which definitely smells like chipidea.
> > > >
> > > > It creates host/device/otg platform device according to dr_mode from
> > > > the device tree.
> > >
> > > Again, that's software specific. What I'd like to know is whether the
> > > *hardware* could be handled by the chipidea driver.
> > not understand u, you mean the DT information at there? Those DT information
> > may not be used for i.mx hardware.
>
> The original question was:
>
> There is a driver in the tree called fsl-mph-dr-of.c. Does this driver
> handle a hardware which is compatible to the hardware the chipidea
> driver handles?
>
> I think the answer is yes, because said driver registers a ehci device,
> or fsl-usb2-udc device (the same we used on i.MX). This hardware also
> has a PORTSC register. All this seems to suggest that
>
> drivers/usb/host/fsl-mph-dr-of.c
> drivers/usb/host/ehci-fsl.c
> drivers/usb/otg/fsl_otg.c
> drivers/usb/gadget/fsl_usb2_udc.h
> drivers/usb/gadget/fsl_udc_core.c
>
> Could be replaced by the chipidea driver.
Yes, after creating a PowerPC's glue driver, like ci13xxx_ppc, or whatever.
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Lorenzo Pieralisi @ 2013-02-01 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BA728.4060300@ti.com>
On Fri, Feb 01, 2013 at 11:29:44AM +0000, Santosh Shilimkar wrote:
> + Lorenzo,
>
> On Thursday 31 January 2013 10:35 PM, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > mach-socfpga is another platform that needs to use
> > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
> >
> > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > Acked-by: Simon Horman <horms+renesas@verge.net.au>
> > Tested-by: Pavel Machek <pavel@denx.de>
> > Reviewed-by: Pavel Machek <pavel@denx.de>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > ---
> > arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
> > arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
> > arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
> > arch/arm/mm/cache-v7.S | 46 ++++++++++++++++++++++++++++++++++++
> > 4 files changed, 46 insertions(+), 138 deletions(-)
> >
> [..]
>
> > diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> > index 7539ec2..15451ee 100644
> > --- a/arch/arm/mm/cache-v7.S
> > +++ b/arch/arm/mm/cache-v7.S
> > @@ -19,6 +19,52 @@
> > #include "proc-macros.S"
> >
> > /*
> > + * The secondary kernel init calls v7_flush_dcache_all before it enables
> > + * the L1; however, the L1 comes out of reset in an undefined state, so
> > + * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
> > + * of cache lines with uninitialized data and uninitialized tags to get
> > + * written out to memory, which does really unpleasant things to the main
> > + * processor. We fix this by performing an invalidate, rather than a
> > + * clean + invalidate, before jumping into the kernel.
> > + *
> > + * This function is cloned from arch/arm/mach-tegra/headsmp.S, and needs
> > + * to be called for both secondary cores startup and primary core resume
> > + * procedures.
> > + */
> > +ENTRY(v7_invalidate_l1)
> Now since we are moving the code under common place, probably we should
> update this a function a bit so that it invalidates the CPU cache till
> line of unification. Just to be consistent with other flush API.
>
> Lorenzo,
> Does that make sense ?
Well, on latest processors (A15, A7) caches are invalidated on reset unless
the chip is programmed to skip that on reset (ie L2 retained).
But it makes sense, for sure it should not be called v7_invalidate_l1,
but invalidate_louis, and instead of forcing level 0 we should be
reading LoUIS and invalidate up to that level as we do in the clean and
invalidate function.
Is it worth adding a v7 cache function where the only difference wrt the clean
and invalidate operation is a coprocessor opcode ? Probably not IMHO, why add
the set/way loop again ?
It is never called from C code, so I do not think there is a point in
adding a C API either.
Lorenzo
^ permalink raw reply
* [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
From: Matt Porter @ 2013-02-01 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359698501.14894.74.camel@cumari.coelho.fi>
On Fri, Feb 01, 2013 at 08:01:41AM +0200, Luciano Coelho wrote:
> On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote:
> > On Thu, Jan 31, 2013 at 08:58:39PM +0000, Arnd Bergmann wrote:
> > > On Thursday 31 January 2013, Matt Porter wrote:
> > > > On Wed, Jan 30, 2013 at 09:32:58AM +0000, Arnd Bergmann wrote:
> > > > > On Wednesday 30 January 2013, Matt Porter wrote:
> > > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
> > > > > > + of_dma_controller_register(dev->of_node,
> > > > > > + of_dma_simple_xlate,
> > > > > > + &edma_filter_info);
> > > > > > + }
> > > > >
> > > > > How do you actually deal with the problem mentioned by Padma, that
> > > > > the filter function does not know which edma instance it is looking
> > > > > at? If you assume that there can only be a single edma instance in
> > > > > the system, that is probably a limitation that should be documented
> > > > > somewhere, and ideally the probe() function should check for that.
> > > >
> > > > I make an assumption of one edma instance in the system in the case of
> > > > DT being populated. This is always true right now as the only SoC with
> > > > two EDMA controllers in existence is Davinci DA850. Until recently,
> > > > Davinci had no DT support. Given the steady work being done today on DT
> > > > support for DA850, it'll probably be something needed in 3.10.
> > > >
> > > > I will add a comment and check in probe() to capture this assumption
> > > > and then plan to update separately to support DA850 booting from DT.
> > >
> > > Ok, sounds good. Hopefully by then we will already have a nicer
> > > way to write an xlate function that does not rely on a filter
> > > function.
> >
> > Yes, it would be nice to avoid what Padma had to do. I should have
> > mentioned also that the second EDMA on DA850 has no DMA events of
> > immediate use on it anyway. All the in-kernel users use events on the
> > first controller, except for the second MMC instance. That's only used
> > for a wl12xx module on the EVM and that driver has no DT support so it
> > doesn't matter yet in the DT case. Because of this, DA850 can actually
> > add EDMA DT support immediately (on top of this series) and add DMA
> > support to the DT support already posted for the Davinci SPI and MMC
> > client drivers.
>
> I haven't followed this whole discussion in details, but please notice
> that I'm aiming to get DT support for the WiLink modules (wlcore,
> wl12xx...) for 3.10. ;)
Great, looks like we'll all be synced then. ;)
-Matt
^ permalink raw reply
* [PATCH, RFC] default machine descriptor for multiplatform
From: Santosh Shilimkar @ 2013-02-01 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1638002.UJ7zfj1Wn5@wuerfel>
On Thursday 31 January 2013 11:21 PM, Arnd Bergmann wrote:
> This is what I think it would look like to do a default platform
> with an empty machine descriptor on ARM. It makes the few required
> entries in the descriptor optional by using the new irqchip_init()
> and clocksource_of_init() functions as defaults, and adds
> a fallback for the DT case to customize_machine to probe all
> the default devices.
>
> For the case that CONFIG_MULTIPLATFORM is enabled, it then
> adds a machine descriptor that never matches any machine but
> is used as a fallback if nothing else matches.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
This is indeed a nice update towards consolidation. Though
on OMAP, we need to do some work to effectively get rid
of machine, time and irq inits. Will add this task in my
TODO queue.
Regards,
Santosh
^ permalink raw reply
* [PATCHv5 15/16] ARM: hyp: initialize CNTVOFF to zero
From: Mark Rutland @ 2013-02-01 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201111350.GA1970@linaro.org>
On Fri, Feb 01, 2013 at 11:13:50AM +0000, Dave Martin wrote:
> On Thu, Jan 31, 2013 at 12:15:38PM +0000, Mark Rutland wrote:
> > From: Marc Zyngier <Marc.Zyngier@arm.com>
> >
> > In order to be able to use the virtual counter in a safe way,
> > make sure it is initialized to zero before dropping to SVC.
> >
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Dave Martin <dave.martin@arm.com>
> > ---
> > arch/arm/kernel/hyp-stub.S | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> > index 65b2417..455603a 100644
> > --- a/arch/arm/kernel/hyp-stub.S
> > +++ b/arch/arm/kernel/hyp-stub.S
> > @@ -152,6 +152,9 @@ THUMB( orr r7, #(1 << 30) ) @ HSCTLR.TE
> > mrc p15, 4, r7, c14, c1, 0 @ CNTHCTL
> > orr r7, r7, #3 @ PL1PCEN | PL1PCTEN
> > mcr p15, 4, r7, c14, c1, 0 @ CNTHCTL
> > + mov r6, #0
> > + mov r7, #0
> > + mcrr p15, 4, r6, r7, c14 @ CNTVOFF
>
> Is this required for safety, or is it more a sanity feature?
This makes more sense with the next patch, which makes the arch_timer
driver always use the virtual counters (to avoid indirection in the fast
path and messy races with the setup of function pointers otherwise).
It's required for safety when hyp mode is enabled, and the arch_timer
driver uses the physical timers in combination with the virtual
counters. Either the driver has to apply CNTVOFF manually when setting
the physical timers, or the physical timers and virtual counters need
the same view of time (i.e. CNTVOFF == 0).
It also brings us in line with arm64, which always uses the virtual
counter for its vDSO.
>
> The architected timer counters are supposed to be monotonic time sources
> only, so applying a random offset shouldn't really change anything.
This is true except when we want to use the physical timers as described above.
>
> The main thing I can think of is that it is easier for the host to
> manage guests' virtual counter offsets if the host's offset is 0 (and
> we don't really want to be changing the host offset after the host kernel
> boots).
That's pretty much it. We don't want to have to further separate the handling
of the timer for host and guest. By having CNTVOFF as zero for the host, we
don't need to duplicate reading of the timers and/or incur an additional
overhead on reading them.
Thanks,
Mark.
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201113233.GJ23505@n2100.arm.linux.org.uk>
On Friday 01 February 2013 05:02 PM, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
>> Now since we are moving the code under common place, probably we should
>> update this a function a bit so that it invalidates the CPU cache till
>> line of unification. Just to be consistent with other flush API.
>
> Hmm. Do you really want a CPU being brought up to do that to the PoU,
> every time that it is brought up? I thought you wanted to get rid of
> that kind of stuff from the hotplug paths so that a CPU being brought
> up/taken down doesn't affect the caches for the other CPUs within the
> inner sharable domain.
>
You are right. We already git rid of the flush of all cache levels
in hotplug and wakeup paths and now it is restricted till the PoU.
Assuming for the current v7 machines, PoU is L2, invalidating the cache
*till* PoU means only CPU local cache. So the API will in a way
invalidate only local cache.
May be I am missing your point here.
Regards,
Santosh
^ permalink raw reply
* [PATCHv5 15/16] ARM: hyp: initialize CNTVOFF to zero
From: Marc Zyngier @ 2013-02-01 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201111350.GA1970@linaro.org>
Hi Dave,
On 01/02/13 11:13, Dave Martin wrote:
> On Thu, Jan 31, 2013 at 12:15:38PM +0000, Mark Rutland wrote:
>> From: Marc Zyngier <Marc.Zyngier@arm.com>
>>
>> In order to be able to use the virtual counter in a safe way,
>> make sure it is initialized to zero before dropping to SVC.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: Dave Martin <dave.martin@arm.com>
>> ---
>> arch/arm/kernel/hyp-stub.S | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
>> index 65b2417..455603a 100644
>> --- a/arch/arm/kernel/hyp-stub.S
>> +++ b/arch/arm/kernel/hyp-stub.S
>> @@ -152,6 +152,9 @@ THUMB( orr r7, #(1 << 30) ) @ HSCTLR.TE
>> mrc p15, 4, r7, c14, c1, 0 @ CNTHCTL
>> orr r7, r7, #3 @ PL1PCEN | PL1PCTEN
>> mcr p15, 4, r7, c14, c1, 0 @ CNTHCTL
>> + mov r6, #0
>> + mov r7, #0
>> + mcrr p15, 4, r6, r7, c14 @ CNTVOFF
>
> Is this required for safety, or is it more a sanity feature?
>
> The architected timer counters are supposed to be monotonic time sources
> only, so applying a random offset shouldn't really change anything.
>
> The main thing I can think of is that it is easier for the host to
> manage guests' virtual counter offsets if the host's offset is 0 (and
> we don't really want to be changing the host offset after the host kernel
> boots).
As you noticed, the offset itself doesn't matter as long as it is
constant. However, setting it to zero makes it nicer to the hypervisor:
no need to remember the host offset, just reset it to zero when exiting
a guest.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BA728.4060300@ti.com>
On Fri, Feb 01, 2013 at 04:59:44PM +0530, Santosh Shilimkar wrote:
> Now since we are moving the code under common place, probably we should
> update this a function a bit so that it invalidates the CPU cache till
> line of unification. Just to be consistent with other flush API.
Hmm. Do you really want a CPU being brought up to do that to the PoU,
every time that it is brought up? I thought you wanted to get rid of
that kind of stuff from the hotplug paths so that a CPU being brought
up/taken down doesn't affect the caches for the other CPUs within the
inner sharable domain.
^ permalink raw reply
* [PATCH 2/4] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by DT
From: Mark Rutland @ 2013-02-01 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201043931.GA11947@verge.net.au>
On Fri, Feb 01, 2013 at 04:39:31AM +0000, Simon Horman wrote:
> On Fri, Feb 01, 2013 at 10:47:06AM +0900, Simon Horman wrote:
> > On Fri, Feb 01, 2013 at 09:34:10AM +0900, Simon Horman wrote:
> > > On Fri, Feb 01, 2013 at 09:11:19AM +0900, Simon Horman wrote:
> > > > On Thu, Jan 31, 2013 at 12:32:13PM +0000, Mark Rutland wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Thu, Jan 31, 2013 at 01:50:49AM +0000, Simon Horman wrote:
> > > > > > This allows the GIC interrupt controller of the r8a7779 SoC to be
> > > > > > initialised using a flattened device tree blob.
> > > > > >
> > > > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > > > > ---
> > > > > > arch/arm/boot/dts/r8a7779.dtsi | 40 ++++++++++++++++++++++++++
> > > > > > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > > > > > arch/arm/mach-shmobile/intc-r8a7779.c | 27 +++++++++++++----
> > > > > > 3 files changed, 62 insertions(+), 6 deletions(-)
> > > > > > create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> > > > > > new file mode 100644
> > > > > > index 0000000..eadc12e
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm/boot/dts/r8a7779.dtsi
> > > > > > @@ -0,0 +1,40 @@
> > > > > > +/*
> > > > > > + * Device Tree Source for Renesas r8a7740
> > > > > > + *
> > > > > > + * Copyright (C) 2013 Renesas Solutions Corp.
> > > > > > + * Copyright (C) 2013 Simon Horman
> > > > > > + *
> > > > > > + * This file is licensed under the terms of the GNU General Public License
> > > > > > + * version 2. This program is licensed "as is" without any warranty of any
> > > > > > + * kind, whether express or implied.
> > > > > > + */
> > > > > > +
> > > > > > +/include/ "skeleton.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > + compatible = "renesas,r8a7779";
> > > > > > +
> > > > > > + cpus {
> > > > > > + cpu at 0 {
> > > > > > + compatible = "arm,cortex-a9";
> > > > > > + };
> > > > > > + cpu at 1 {
> > > > > > + compatible = "arm,cortex-a9";
> > > > > > + };
> > > > > > + cpu at 2 {
> > > > > > + compatible = "arm,cortex-a9";
> > > > > > + };
> > > > > > + cpu at 3 {
> > > > > > + compatible = "arm,cortex-a9";
> > > > > > + };
> > > > > > + };
> > > > >
> > > > > Sorry to sound like a broken record, but it'd be good to see reg and
> > > > > device_type set here.
> > > >
> > > > Sure, will do.
> > > >
> > > > > > +
> > > > > > + gic: interrupt-controller at f0001000 {
> > > > > > + compatible = "arm,cortex-a9-gic";
> > > > > > + #interrupt-cells = <3>;
> > > > > > + #address-cells = <1>;
> > > > >
> > > > > Why is #address-cells needed here (and without #size-cells)? I see it's in the
> > > > > binding document example, but I can't figure out why.
> > > >
> > > > Its here because I copied the example.
> > > > I will see about removing it from here.
> > > >
> > > > > > + interrupt-controller;
> > > > > > + reg = <0xf0001000 0x1000>,
> > > > > > + <0xf0000100 0x100>;
> > > > > > + };
> > > > > > +};
> > >
> > > A revised patch is below. I should also remove "#address-cells = <1>" from
> > > gic in arch/arm/boot/dts/sh73a0.dtsi if it is indeed unnecessary.
I just poked Rob and Grant in another subthread. Hopefully they'll be able to
tell us if there's something we missed.
>
> One more time:
>
> From 6031d5177193431a57392dfd2f38be0676bdb535 Mon Sep 17 00:00:00 2001
> From: Simon Horman <horms+renesas@verge.net.au>
> Date: Tue, 29 Jan 2013 14:21:46 +0900
> Subject: [PATCH] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by
> DT
>
> This allows the GIC interrupt controller of the r8a7779 SoC to be
> initialised using a flattened device tree blob.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
>
> v3
> * Fix copy-paste error and use unique reg values for each CPU
>
> v2
> As suggested by Mark Rutland
> * Add reg and device_type to cpus
> * Remove #address-cells from gic
> ---
> arch/arm/boot/dts/r8a7779.dtsi | 50 ++++++++++++++++++++++++++
> arch/arm/mach-shmobile/include/mach/common.h | 1 +
> arch/arm/mach-shmobile/intc-r8a7779.c | 27 ++++++++++----
> 3 files changed, 72 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
>
> diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> new file mode 100644
> index 0000000..8c6d52c
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7779.dtsi
> @@ -0,0 +1,50 @@
> +/*
> + * Device Tree Source for Renesas r8a7740
> + *
> + * Copyright (C) 2013 Renesas Solutions Corp.
> + * Copyright (C) 2013 Simon Horman
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "renesas,r8a7779";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + };
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <1>;
> + };
> + cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <2>;
> + };
> + cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <3>;
> + };
> + };
> +
> + gic: interrupt-controller at f0001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0xf0001000 0x1000>,
> + <0xf0000100 0x100>;
> + };
> +};
Thanks, this looks much better now! :)
For the dtsi: Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Arnd Bergmann @ 2013-02-01 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131224459.GA11846@obsidianresearch.com>
On Thursday 31 January 2013, Jason Gunthorpe wrote:
> On Thu, Jan 31, 2013 at 08:46:22PM +0000, Arnd Bergmann wrote:
>
> > > If it is 0xDEAD0000, then Thomas has to keep what he has now, you
> > > can't mess with this address. Verify that the full 32 bit address
> > > exactly matching the MBUS window address is written to the PCI-PCI
> > > bridge IO base/limit registers.
> >
> > If you do this, you break all sorts of expectations in the kernel and
> > I guess you'd have to set the io_offset value of that bus to 0x21530000
> > in order to make Linux I/O port 0 go to the first byte of the window
> > and come out as 0xDEAD0000 on the bus, but you still won't be able to
> > use legacy devices with hardcoded I/O port numbers.
>
> I'm not sure exactly how the PCI core handles this, but it does look
> like pci_add_resource_offset via io_offset is the answer. I'm not sure
> what goes in the struct resource passed to the PCI core - the *bus* IO
> address range or the *kernel* IO address range..
IO Resources are always expressed in the kernel's view, so they are in
the range from 0 to IO_SPACE_LIMIT. The idea is that you can have multiple
buses that each have their own address space start at 0, but can put
them into the kernel address space at a different address.
Each device on any bus can still use I/O addresses starting at zero,
and you could have e.g. a VGA card on two buses each respond to I/O cycles
on port 0x3c0, but the PCI core will translate the resources to appear
in the kernel space at 0x103c0 for the second one.
> > > If it is 0x00000000 then the mmap scheme I outlined before must be
> > > used, and verify that only 0->0xFFFF is written to the PCI-PCI bridge
> > > IO base/limit registers..
> >
> > For the primary bus, yes, but there are still two options for the
> > second one: you can either start at 0 again or you can continue
>
> No, for *all* links. You use a mmap scheme with 4k granularity, I
> explained in a past email, but to quickly review..
>
> - Each link gets 64k of reserved physical address space for IO,
> this is just set aside, no MBUS windows are permantently assigned.
> - Linux is told to use a 64k IO range with bus IO address 0->0xFFFF
> - When the IO base/limit register in the link PCI-PCI bridge is programmed
> the driver gets a 4k aligned region somewhere from 0->0xFFFF and then:
> - Allocates a 64k MBUS window that translates physical address
> 0xZZZZxxxx to IO bus address 0x0000xxxx (goes in the TLP) for
> that link
> - Uses pci_ioremap_io to map the fraction of the link's 64k MBUS window
> allocated to that bridge to the correct offset in the
> PCI_IO_VIRT_BASE region
We'd have to change pci_ioremap_io to allow mapping less than 64k, but
yes, that would work, too. I don't see an advantage to it though,
other than having io_offset always be zero.
> > at 0x10000 as we do for mv78xx0 and kirkwood for instance. Both
> > approaches probably have their merit.
>
> Kirkwood uses the MBUS remapping registers to set the TLP address of
> link 0 to start at 0 and of link 1 to start at 0x10000 - so it is
> consistent with what you describe..
Right, so it also uses io_offset = 0 all the time, which means the
bus I/O port numbers are identical to the Linux I/O port numbers,
but they go beyond 64K on the bus on the second and later links.
> However, this is a suboptimal way to run the HW. It would be much
> better to place each link in a seperate PCI domain and have each link
> start its bus IO address at 0, and assign the kernel IO address in
> sequential 64k blocks as today.
I agree.
Arnd
^ 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