* [PATCH v5 01/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks
From: Geert Uytterhoeven @ 2014-02-04 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391527445-14881-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v5:
- Rebased on top of renesas-devel-v3.14-rc1-20140204
v4:
- The platform device basename was changed from "rspi" to "rspi-rz"
v3:
- No changes
v2:
- Correct platform device names ("rspi%u" -> "rspi.%u")
arch/arm/mach-shmobile/clock-r7s72100.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-r7s72100.c b/arch/arm/mach-shmobile/clock-r7s72100.c
index dd8ce87596de..ffb0fff41375 100644
--- a/arch/arm/mach-shmobile/clock-r7s72100.c
+++ b/arch/arm/mach-shmobile/clock-r7s72100.c
@@ -22,12 +22,14 @@
#include <mach/common.h>
#include <mach/r7s72100.h>
-/* registers */
+/* Frequency Control Registers */
#define FRQCR 0xfcfe0010
#define FRQCR2 0xfcfe0014
+/* Standby Control Registers */
#define STBCR3 0xfcfe0420
#define STBCR4 0xfcfe0424
#define STBCR9 0xfcfe0438
+#define STBCR10 0xfcfe043c
#define PLL_RATE 30
@@ -145,11 +147,19 @@ struct clk div4_clks[DIV4_NR] = {
| CLK_ENABLE_ON_INIT),
};
-enum { MSTP97, MSTP96, MSTP95, MSTP94,
+enum {
+ MSTP107, MSTP106, MSTP105, MSTP104, MSTP103,
+ MSTP97, MSTP96, MSTP95, MSTP94,
MSTP47, MSTP46, MSTP45, MSTP44, MSTP43, MSTP42, MSTP41, MSTP40,
- MSTP33, MSTP_NR };
+ MSTP33, MSTP_NR
+};
static struct clk mstp_clks[MSTP_NR] = {
+ [MSTP107] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 7, 0), /* RSPI0 */
+ [MSTP106] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 6, 0), /* RSPI1 */
+ [MSTP105] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 5, 0), /* RSPI2 */
+ [MSTP104] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 4, 0), /* RSPI3 */
+ [MSTP103] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 3, 0), /* RSPI4 */
[MSTP97] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 7, 0), /* RIIC0 */
[MSTP96] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 6, 0), /* RIIC1 */
[MSTP95] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 5, 0), /* RIIC2 */
@@ -176,6 +186,11 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("cpu_clk", &div4_clks[DIV4_I]),
/* MSTP clocks */
+ CLKDEV_DEV_ID("rspi-rz.0", &mstp_clks[MSTP107]),
+ CLKDEV_DEV_ID("rspi-rz.1", &mstp_clks[MSTP106]),
+ CLKDEV_DEV_ID("rspi-rz.2", &mstp_clks[MSTP105]),
+ CLKDEV_DEV_ID("rspi-rz.3", &mstp_clks[MSTP104]),
+ CLKDEV_DEV_ID("rspi-rz.4", &mstp_clks[MSTP103]),
CLKDEV_DEV_ID("fcfee000.i2c", &mstp_clks[MSTP97]),
CLKDEV_DEV_ID("fcfee400.i2c", &mstp_clks[MSTP96]),
CLKDEV_DEV_ID("fcfee800.i2c", &mstp_clks[MSTP95]),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board integration
From: Geert Uytterhoeven @ 2014-02-04 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series contains SoC and board integration for
1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
It was rebased on top of renesas-devel-v3.14-rc1-20140204.
It was tested on the r7s72100-based Genmai reference board using loopback
mode, and on the r8a7791-based Koelsch reference board using the Spansion
s25fl512s SPI FLASH.
- [v5 01/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks
- [v5 02/11] ARM: shmobile: genmai legacy: Add RSPI support
- [v3 03/11] ARM: shmobile: genmai defconfig: Enable RSPI
- [v3 04/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks for DT
- [v5 05/11] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
- [v4 06/11] ARM: shmobile: r8a7791 clock: add QSPI clocks
- [v4 07/11] ARM: shmobile: koelsch legacy: Add QSPI support
- [v4 08/11] ARM: shmobile: koelsch defconfig: Enable RSPI and
- [v3 09/11] ARM: shmobile: r8a7791 dtsi: Add QSPI node
- [v3 10/11] ARM: shmobile: koelsch dts: Add QSPI nodes
- [v2 11/11] ARM: shmobile: lager legacy: Switch QSPI to named IRQs
All of these should be safe to apply, without compile-time or run-time
dependencies on other parts.
Actual functioning for some parts may depend on RSPI work queued up for
3.15 in the spi tree.
Compared to previous submission, the following have been postponed:
- [v4 03/15] [WIP] ARM: shmobile: genmai legacy: Add preliminary RSPI
pinmux setup
This depends on the to-be-written non-DT pinmux configuration for
r7s72100.
- [v4 07/15] ARM: shmobile: genmai reference dts: Add RSPI nodes
This depends on Magnus' "ARM: shmobile: r7s72100 GPIO and PINCTRL device
nodes"
- [v1 14/15] ARM: shmobile: koelsch legacy: Enable Quad SPI transfers for
the SPI FLASH
- [v1 15/15] ARM: shmobile: koelsch dts: Enable Quad SPI transfers
These two depend on the RSPI Dual/Quad work queued up in the spi tree.
After applying the r8a7791/Koelsch patches above, the mainline RSPI/QSPI
driver will work fine. But enabling Quad SPI transfers in board support
code or DT without the corresponding support in the RSPI driver would
cause a regression.
Please apply this series, Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204150156.GC4627@beef>
> > ... then you'll still need this.
>
> Yes, I was far too vague..I'm going to stop explicitly populating the
> data field.
>
> static const struct of_device_id bcm59056_of_match[] = {
> { .compatible = "brcm,bcm59056"},
> { }
> };
+1
> > And I don't think you can drop this, as the I2C subsystem still
> > insists on it.
>
> Agreed. I'm just dropping explicit population of the driver_data field
> here.
>
> static const struct i2c_device_id bcm59056_i2c_id[] = {
> { "bcm59056" },
> { }
> };
+1
> > I think you need to keep this to supply the silly I2C ID table.
> >
> > I would just omit the '.data = (void *) VERSION' from the
> > of_match_table until you require it.
>
> Well, it's not even necessary for I2C ID table. the I2C subsystem is
> happy with just a matching entry on the i2c_device_id name field and
> NULL driver_data. palmas is implemented in this manner.
Guess what? +1 :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Nishanth Menon @ 2014-02-04 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0E098.3050404@ti.com>
On 02/04/2014 06:44 AM, Balaji T K wrote:
> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
>> When device is booted using devicetree, platforms impacted by
>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>> indicates that the module cannot do multi-block transfers.
>>
>> Handle this by providing a boolean flag to indicate to driver that it is
>> working on a hardware with mentioned limitation.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>
>> This explains the logs I see:
>> OMAP3430 LDP (ES2.2):
>> uImage only boot: http://slexy.org/raw/s2YrbMAi7c
>> uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
>>
>> With the following flag set, device is now able to consistently boot with
>> device tree supported uImage+dtb concat boot.
>>
>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 ++
>> drivers/mmc/host/omap_hsmmc.c | 3 +++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> index 8c8908a..ab36f8b 100644
>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -26,6 +26,8 @@ specifier is required.
>> dma-names: List of DMA request names. These strings correspond
>> 1:1 with the DMA specifiers listed in dmas. The string naming is
>> to be "rx" and "tx" for RX and TX DMA requests, respectively.
>> +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
>> +multiblock reads
>
> Rather than ti,errata.. specific property, something like
> caps no/disable multiblock read is more readable in my opinion, Otherwise
Is'nt the better definition to state i have quirk X and allow the
driver to do the necessary thing/things needed to handle quirk X? in
this case, there is just one thing to do: broken multi_block_read, in
the case of other quirks, there might be more than 1 thing to do.. let
driver figure that out, dts just states the h/w capabilty or in this
case, the quirk capability.
>
> Acked-by: Balaji T K <balajitk@ti.com>
>
>>
>> Examples:
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 014bfe5..f2d5940 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
>> if (of_find_property(np, "ti,dual-volt", NULL))
>> pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
>>
>> + if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
>> + pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
>> +
>> /* This driver only supports 1 slot */
>> pdata->nr_slots = 1;
>> pdata->slots[0].switch_pin = cd_gpio;
>>
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] ARM: dts: omap3-ldp: fix mmc configuration
From: Nishanth Menon @ 2014-02-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0E109.30801@ti.com>
On 02/04/2014 06:46 AM, Balaji T K wrote:
> On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
>> MMC1 is the only MMC interface available on the platform. Further,
>> since the platform is based on older revision of SoC which is not
>> capable of doing multi-block writes, mark it so and add pinmux
>
> s/writes/read
arrgh.. yes.
>
> Thanks and Regards,
> Balaji T K
>
>> to ensure that all relevant pins are configured for non-MMC boot
>> mode.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> ti,erratum-2.1.1.128 introduced in https://patchwork.kernel.org/patch/3514851/
>> hence depends on the same.
>> arch/arm/boot/dts/omap3-ldp.dts | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
>> index ddce0d8..bc0cc66 100644
>> --- a/arch/arm/boot/dts/omap3-ldp.dts
>> +++ b/arch/arm/boot/dts/omap3-ldp.dts
>> @@ -176,6 +176,17 @@
>> &mmc1 {
>> vmmc-supply = <&vmmc1>;
>> bus-width = <4>;
>> + ti,erratum-2.1.1.128;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> +};
>> +
>> +&mmc2 {
>> + status="disabled";
>> +};
>> +
>> +&mmc3 {
>> + status="disabled";
>> };
>>
>> &omap3_pmx_core {
>> @@ -209,6 +220,17 @@
>> 0x174 (PIN_OUTPUT | MUX_MODE0) /* hsusb0_stp.hsusb0_stp */
>> >;
>> };
>> +
>> + mmc1_pins: pinmux_mmc1_pins {
>> + pinctrl-single,pins = <
>> + OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.mmc1_clk */
>> + OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.mmc1_cmd */
>> + OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.mmc1_dat0 */
>> + OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.mmc1_dat1 */
>> + OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.mmc1_dat2 */
>> + OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.mmc1_dat3 */
>> + >;
>> + };
>> };
>>
>> &usb_otg_hs {
>>
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/2] PM / OPP: Add support for 'boost' mode OPP
From: Nishanth Menon @ 2014-02-04 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506890-7335-2-git-send-email-thomas.ab@samsung.com>
On 02/04/2014 03:41 AM, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
> support for CPU boost mode. This patch adds support for finding available
> boost OPPs from device tree and marking them as usable in boost mode.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
Why is a cpufreq feature being pushed on to OPP library? you can very
well have a property boot-frequencies = < a b c > and be done with the
job.
I agree with Rob's comment that this is something we have to discuss
in wider "add features to an OPP" discussion[1].
[1] http://marc.info/?t=139108946400001&r=1&w=2
> drivers/base/power/opp.c | 69 +++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 56 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index 2553867..de4d52d 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -62,6 +62,7 @@ struct dev_pm_opp {
> struct list_head node;
>
> bool available;
> + bool boost;
> unsigned long rate;
> unsigned long u_volt;
>
> @@ -380,10 +381,12 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device *dev,
> EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
>
> /**
> - * dev_pm_opp_add() - Add an OPP table from a table definitions
> + * dev_pm_opp_add_flags() - Add an OPP to device OPP list with flags
> * @dev: device for which we do this operation
> * @freq: Frequency in Hz for this OPP
> * @u_volt: Voltage in uVolts for this OPP
> + * @available: initial availability of the OPP with adding it to the list.
> + * @boost: availability of this opp in controller's boost operating mode.
> *
> * This function adds an opp definition to the opp list and returns status.
> * The opp is made available by default and it can be controlled using
> @@ -395,7 +398,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
> * that this function is *NOT* called under RCU protection or in contexts where
> * mutex cannot be locked.
> */
> -int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> +static int dev_pm_opp_add_flags(struct device *dev, unsigned long freq,
> + unsigned long u_volt, bool available, bool boost)
> {
> struct device_opp *dev_opp = NULL;
> struct dev_pm_opp *opp, *new_opp;
> @@ -441,7 +445,8 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> new_opp->dev_opp = dev_opp;
> new_opp->rate = freq;
> new_opp->u_volt = u_volt;
> - new_opp->available = true;
> + new_opp->available = available;
> + new_opp->boost = boost;
>
> /* Insert new OPP in order of increasing frequency */
> head = &dev_opp->opp_list;
> @@ -462,6 +467,27 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ADD, new_opp);
> return 0;
> }
> +
> +/**
> + * dev_pm_opp_add() - Add an OPP table from a table definitions
> + * @dev: device for which we do this operation
> + * @freq: Frequency in Hz for this OPP
> + * @u_volt: Voltage in uVolts for this OPP
> + *
> + * This function adds an opp definition to the opp list and returns status.
> + * The opp is made available by default and it can be controlled using
> + * dev_pm_opp_enable/disable functions.
> + *
> + * Locking: The internal device_opp and opp structures are RCU protected.
> + * Hence this function internally uses RCU updater strategy with mutex locks
> + * to keep the integrity of the internal data structures. Callers should ensure
> + * that this function is *NOT* called under RCU protection or in contexts where
> + * mutex cannot be locked.
> + */
> +int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> +{
> + return dev_pm_opp_add_flags(dev, freq, u_volt, true, false);
> +}
> EXPORT_SYMBOL_GPL(dev_pm_opp_add);
>
> /**
> @@ -651,7 +677,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>
> list_for_each_entry(opp, &dev_opp->opp_list, node) {
> if (opp->available) {
> - freq_table[i].driver_data = i;
> + freq_table[i].driver_data =
> + opp->boost ? CPUFREQ_BOOST_FREQ : i;
> freq_table[i].frequency = opp->rate / 1000;
> i++;
> }
> @@ -701,19 +728,14 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(struct device *dev)
> }
>
> #ifdef CONFIG_OF
> -/**
> - * of_init_opp_table() - Initialize opp table from device tree
> - * @dev: device pointer used to lookup device OPPs.
> - *
> - * Register the initial OPP table with the OPP library for given device.
> - */
> -int of_init_opp_table(struct device *dev)
> +static int of_parse_opp_table(struct device *dev, const char *prop_name,
> + bool boost)
> {
> const struct property *prop;
> const __be32 *val;
> int nr;
>
> - prop = of_find_property(dev->of_node, "operating-points", NULL);
> + prop = of_find_property(dev->of_node, prop_name, NULL);
> if (!prop)
> return -ENODEV;
> if (!prop->value)
> @@ -734,7 +756,7 @@ int of_init_opp_table(struct device *dev)
> unsigned long freq = be32_to_cpup(val++) * 1000;
> unsigned long volt = be32_to_cpup(val++);
>
> - if (dev_pm_opp_add(dev, freq, volt)) {
> + if (dev_pm_opp_add_flags(dev, freq, volt, true, boost)) {
> dev_warn(dev, "%s: Failed to add OPP %ld\n",
> __func__, freq);
> continue;
> @@ -744,5 +766,26 @@ int of_init_opp_table(struct device *dev)
>
> return 0;
> }
> +
> +/**
> + * of_init_opp_table() - Initialize opp table from device tree
> + * @dev: device pointer used to lookup device OPPs.
> + *
> + * Register the initial OPP table with the OPP library for given device.
> + * Additional "boost" operating points of the controller, if any, are
> + * specified with "boost-opp" property.
> + */
> +int of_init_opp_table(struct device *dev)
> +{
> + int ret;
> +
> + ret = of_parse_opp_table(dev, "operating-points", false);
> + if (!ret) {
> + ret = of_parse_opp_table(dev, "boost-opp", true);
> + if (ret == -ENODEV)
> + ret = 0;
> + }
> + return ret;
> +}
> EXPORT_SYMBOL_GPL(of_init_opp_table);
> #endif
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [Xen-devel] [PATCH v9 0/5] xen/arm/arm64: CONFIG_PARAVIRT and stolen ticks accounting
From: Konrad Rzeszutek Wilk @ 2014-02-04 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1401091755390.21510@kaball.uk.xensource.com>
On Thu, Jan 09, 2014 at 06:15:07PM +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series introduces stolen ticks accounting for Xen on ARM and
> ARM64.
> Stolen ticks are clocksource ticks that have been "stolen" from the cpu,
> typically because Linux is running in a virtual machine and the vcpu has
> been descheduled.
> To account for these ticks we introduce CONFIG_PARAVIRT and pv_time_ops
> so that we can make use of:
>
> kernel/sched/cputime.c:steal_account_process_tick
>
>
> Changes in v9:
> - added back missing new files from patches;
> - fix compilation on avr32 (remove patch #5, revert to previous version
> of patch #2).
>
>
>
> Stefano Stabellini (5):
> xen: move xen_setup_runstate_info and get_runstate_snapshot to drivers/xen/time.c
> kernel: missing include in cputime.c
> arm: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops
> arm64: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops
> xen/arm: account for stolen ticks
>
> arch/arm/Kconfig | 20 ++++++++
> arch/arm/include/asm/paravirt.h | 20 ++++++++
> arch/arm/kernel/Makefile | 2 +
> arch/arm/kernel/paravirt.c | 25 ++++++++++
> arch/arm/xen/enlighten.c | 21 +++++++++
> arch/arm64/Kconfig | 20 ++++++++
> arch/arm64/include/asm/paravirt.h | 20 ++++++++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/paravirt.c | 25 ++++++++++
> arch/ia64/xen/time.c | 48 +++----------------
> arch/x86/xen/time.c | 76 +------------------------------
> drivers/xen/Makefile | 2 +-
> drivers/xen/time.c | 91 +++++++++++++++++++++++++++++++++++++
> include/xen/xen-ops.h | 5 ++
> kernel/sched/cputime.c | 3 ++
> 15 files changed, 261 insertions(+), 118 deletions(-)
> create mode 100644 arch/arm/include/asm/paravirt.h
> create mode 100644 arch/arm/kernel/paravirt.c
> create mode 100644 arch/arm64/include/asm/paravirt.h
> create mode 100644 arch/arm64/kernel/paravirt.c
> create mode 100644 drivers/xen/time.c
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git lost_ticks_9
I tried to merge it on top of 3.14-rc1 + stable/for-linus-3.14 (which
has the revert of " xen/grant-table: Avoid m2p_override during mapping"
And I get:
konrad at phenom:~/linux$ git merge stefano/lost_ticks_9
Auto-merging drivers/xen/Makefile
CONFLICT (content): Merge conflict in drivers/xen/Makefile
Auto-merging arch/x86/xen/time.c
CONFLICT (modify/delete): arch/ia64/xen/time.c deleted in HEAD and
modified in stefano/lost_ticks_9. Version stefano/lost_ticks_9 of
arch/ia64/xen/time.c left in tree.
Auto-merging arch/arm64/kernel/Makefile
CONFLICT (content): Merge conflict in arch/arm64/kernel/Makefile
Auto-merging arch/arm64/Kconfig
Auto-merging arch/arm/xen/enlighten.c
CONFLICT (content): Merge conflict in arch/arm/xen/enlighten.c
Auto-merging arch/arm/Kconfig
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Automatic merge failed; fix conflicts and then commit the result.
I presume that is mostly due to David's FIFO queue patches.
Could you kindly rebase it on top 3.14-rc1 and also tack on
Catalin Marinas Ack on the patches?
Thank you!
>
>
> Cheers,
>
> Stefano
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204144731.GA3154@lee--X1>
On Tue, Feb 04, 2014 at 02:47:31PM +0000, Lee Jones wrote:
> Hold your horses. :)
Holding :)
> > > > Add a driver for the BCM59056 PMU multi-function device. The driver
> > > > initially supports regmap initialization and instantiation of the
> > > > voltage regulator device function of the PMU.
> > > >
> > > > Signed-off-by: Matt Porter <mporter@linaro.org>
> > > > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > > > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > > > ---
> > > > drivers/mfd/Kconfig | 8 +++
> > > > drivers/mfd/Makefile | 1 +
> > > > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > > > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > > > 4 files changed, 163 insertions(+)
> > > > create mode 100644 drivers/mfd/bcm59056.c
> > > > create mode 100644 include/linux/mfd/bcm59056.h
>
> <snip>
>
> > > I thought this was a DT only driver? If so, you probably want to use
> > > of_match_device() instead.
> >
> > Correct, I'll use of_match_device()
>
> If you're going to use this ...
>
> <snip>
>
> > > You've gone to the trouble of setting a device version here, but you
> > > don't seem to use it?
> >
> > I'll drop the device version
>
> ... then you'll still need this.
Yes, I was far too vague..I'm going to stop explicitly populating the
data field.
static const struct of_device_id bcm59056_of_match[] = {
{ .compatible = "brcm,bcm59056"},
{ }
};
> > > > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > > > + { "bcm59056", BCM59056 },
> > > > + { }
> > > > +};
> > >
> > > Ah, I guess this is where id->driver comes from.
> > >
> > > It's pretty silly that the I2C subsystem demands the presence of this
> > > table, despite not using it if an of_device_id table is present.
> >
> > It does make it very difficult to follow DT enabled I2C client drivers
> > :( I'll drop the BCM59056 too.
>
> And I don't think you can drop this, as the I2C subsystem still
> insists on it.
Agreed. I'm just dropping explicit population of the driver_data field
here.
static const struct i2c_device_id bcm59056_i2c_id[] = {
{ "bcm59056" },
{ }
};
>
> > > > +/* chip id */
> > > > +#define BCM59056 0
> > >
> > > Lonely, oh so lonely!
> >
> > Understood. Will remove.
>
> I think you need to keep this to supply the silly I2C ID table.
>
> I would just omit the '.data = (void *) VERSION' from the
> of_match_table until you require it.
Well, it's not even necessary for I2C ID table. the I2C subsystem is
happy with just a matching entry on the i2c_device_id name field and
NULL driver_data. palmas is implemented in this manner.
-Matt
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx27-phytec-phycard-s-rdk: Add pinctrl definitions for SDHC2
From: Alexander Shiyan @ 2014-02-04 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391525972-15810-1-git-send-email-shc_work@mail.ru>
This patch adds pinctrl definitions for SDHC2 for Phytec PCA100 RDK board.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
index 04cadfc..1cd3a87 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
@@ -88,6 +88,18 @@
>;
};
+ pinctrl_sdhc2: sdhc2grp {
+ fsl,pins = <
+ MX27_PAD_SD2_CLK__SD2_CLK 0x0
+ MX27_PAD_SD2_CMD__SD2_CMD 0x0
+ MX27_PAD_SD2_D0__SD2_D0 0x0
+ MX27_PAD_SD2_D1__SD2_D1 0x0
+ MX27_PAD_SD2_D2__SD2_D2 0x0
+ MX27_PAD_SD2_D3__SD2_D3 0x0
+ MX27_PAD_SSI3_RXDAT__GPIO3_29 0x0 /* CD */
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX27_PAD_UART1_TXD__UART1_TXD 0x0
@@ -124,6 +136,8 @@
};
&sdhci2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sdhc2>;
cd-gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>;
status = "okay";
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: imx27-phytec-phycard-s-som: Add NFC node
From: Alexander Shiyan @ 2014-02-04 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391525972-15810-1-git-send-email-shc_work@mail.ru>
This patch adds the NFC devicetree node for Phytec PCA100 module.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index a28b6c7..1b62480 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -78,5 +78,26 @@
MX27_PAD_I2C2_SCL__I2C2_SCL 0x0
>;
};
+
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ MX27_PAD_NFRB__NFRB 0x0
+ MX27_PAD_NFCLE__NFCLE 0x0
+ MX27_PAD_NFWP_B__NFWP_B 0x0
+ MX27_PAD_NFCE_B__NFCE_B 0x0
+ MX27_PAD_NFALE__NFALE 0x0
+ MX27_PAD_NFRE_B__NFRE_B 0x0
+ MX27_PAD_NFWE_B__NFWE_B 0x0
+ >;
+ };
};
};
+
+&nfc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+ status = "okay";
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx27-phytec-phycard-s-som: Sort entries
From: Alexander Shiyan @ 2014-02-04 14:59 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 36 ++++++++++++------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index e51e550..a28b6c7 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -29,6 +29,24 @@
status = "okay";
};
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ at24 at 52 {
+ compatible = "at,24c32";
+ pagesize = <32>;
+ reg = <0x52>;
+ };
+};
+
&iomuxc {
imx27-phycard-s-som {
pinctrl_fec1: fec1grp {
@@ -62,21 +80,3 @@
};
};
};
-
-&fec {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-};
-
-&i2c2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c2>;
- status = "okay";
-
- at24 at 52 {
- compatible = "at,24c32";
- pagesize = <32>;
- reg = <0x52>;
- };
-};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Gregory CLEMENT @ 2014-02-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F02816.1050708@gmail.com>
On 04/02/2014 00:36, Sebastian Hesselbarth wrote:
> On 02/04/2014 12:16 AM, Willy Tarreau wrote:
>> On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
>>> On 01/30/14 11:24, Gregory CLEMENT wrote:
>>>> On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
>>>>> This patch set fixes clk init order that went upside-down with
>>>>> v3.14. I haven't really investigated what caused this, but I assume
>>>>> it is related with DT node reordering by addresses.
>>>>
>>>> Can you explain what kind of issue do you observe?
>>>
>>> Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver
>>> gets registered before core-clocks. It therefore cannot resolve it's
>>> parent clock name for tclk and all clock gates will have no parent
>>> clock.
>>>
>>> Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors
>>> poping up, when they calculate a frequency division factors based on
>>> clock gate frequency, which should have been tclk but is 0 now.
>>
>> Well, to be honnest, I have no idea whether your patch is the right way
>> to fix the problem or not, but what I can say is that it fixes such oopses
>> that appear in 3.14-rc1 when booting on mirabox :
>>
>> Division by zero in kernel.
>
> Willy,
>
> you have hit exactly the reason for this patch.
>
> [...]
>> By the way, seeing how often a trick related to the DT is nedeed to solve an
>> oops or a panic, I'm really scared that this whole DT mess is just becoming
>> the exact copy of the ACPI mess (but 15 years later) and we'll experience the
>> same horrible things :-( Sometimes I'm wondering whether there are not too
>> many structural things put in there...
>
> To be precise, it is not a DT-related trick at all. You would have the
> same issues, if you'd register those "low-level" (i.e. early) drivers
> without DT. It is more about missing init ordering, here.
>
> There could be different ways to work this out, even elevating clock
> devices to "normal" probed devices could be possible. I am sure, in the
> long run, it will work out, but now this is a fix for v3.14-rc1.
>
> @Jason, Andrew, Gregory, Thomas:
> Now that v3.14 is out, anything against taking this in as fixes for rc1?
Hi Sebastian,
I am not found of this solution I still think it should be done
at framework level. However we still have this very annoying issue,
and this fix is better than nothing. So I am not against taking this
for rc1 with the hope that it will be later revert with a better
solution.
Thanks,
Gregory
>
> Sebastian
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Toradex Colibri PXA270 Sound Problem
From: Erik Habicht @ 2014-02-04 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Hallo List,
we are using a Toradex PXA270 SoC module with a patch to get the Wolfson
WM9715 working on 2.6.37 (2.6.36, 2.6.35, 2.6.27). It works pretty well.
Now i decided to switch to a newer kernel version. I started with 2.6.38
and modified the patch to compile it. The kernel boot to the
system, but only capturing is working. I get no audio output anymore.
In the previous kernel versions i always use the following amixer settings:
amixer set 'Headphone' 100% on
amixer set 'Speaker Mixer PCM' on
amixer set 'Left HP Mixer PCM' on
amixer set 'Right HP Mixer PCM' on
This is the kernel output. It looks like all versions before:
[ 8.405110] WM9711/WM9712 SoC Audio Codec 0.4
[ 8.457947] pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44)
[ 8.543333] asoc: wm9712-hifi <-> pxa2xx-ac97 mapping ok
[ 8.609104] asoc: wm9712-aux <-> pxa2xx-ac97-aux mapping ok
[ 8.687232] wm97xx-ts 0-0:wm9712-codec: detected a wm9712 codec
[ 8.760968] input: wm97xx touchscreen as
/devices/platform/soc-audio/0-0:wm9712-codec/input/input0
[ 8.875466] ALSA device list:
[ 8.911416] #0: Toradex Colibri
I already tried 3.2.y with the same behavior.
Maybe someone can help me to figure out whats going wrong?
I attached the patches i used:
working = patch-2.6.37.y.patch
not working = patch-2.6.38.y.patch
Best regards,
Erik
_______________________________________________________
Registergericht / Court of jurisdiction: Amtsgericht Gie?en HRB 5708
Gesch?ftsf?hrer / Managing Director: Edith Thiesen, J?rgen Thiesen
USt.-Id: DE 175 623 789
Ust.-Nr: 018 246 00743 FA Fulda
Hauptsitz / Headquarters:
Thiesen Hardware & Software Design GmbH / Im Tiegel 9 / 36367 Wartenberg / Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-2.6.37.y.patch
Type: text/x-patch
Size: 7300 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/d1fce0df/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-2.6.38.y.patch
Type: text/x-patch
Size: 7556 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/d1fce0df/attachment-0003.bin>
^ permalink raw reply
* [PATCH] ARM: pxa: fix various compilation problems
From: Arnd Bergmann @ 2014-02-04 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391518387-5934-1-git-send-email-linus.walleij@linaro.org>
On Tuesday 04 February 2014 13:53:07 Linus Walleij wrote:
> Hi ARM SoC folks: please apply this patch directly to the ARM
> SoC tree fixes branch if you are happy with it.
It's also needed for 3.13-backports, right?
Arnd
^ permalink raw reply
* [PATCH resend 1/2] arm64: defer reloading a task's FPSIMD state to userland resume
From: Ard Biesheuvel @ 2014-02-04 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203163609.GK14112@mudshark.cambridge.arm.com>
On 3 February 2014 17:36, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ard,
>
> On Fri, Jan 31, 2014 at 10:13:15AM +0000, Ard Biesheuvel wrote:
>> If a task gets scheduled out and back in again and nothing has touched
>> its FPSIMD state in the mean time, there is really no reason to reload
>> it from memory. Similarly, repeated calls to kernel_neon_begin() and
>> kernel_neon_end() will preserve and restore the FPSIMD state every time.
>>
>> This patch defers the FPSIMD state restore to the last possible moment,
>> i.e., right before the task re-enters userland. If a task does not enter
>> userland at all (for any reason), the existing FPSIMD state is preserved
>> and may be reused by the owning task if it gets scheduled in again on the
>> same CPU.
>
> The one situation I'm unsure of here is how you deal with the saved fpsimd
> state potentially being updated by a signal handler or a debugger. In this
> case, we probably need to set _TIF_FOREIGN_FPSTATE to force a reload, or are
> you handling this some other way?
>
If I am reading the code correctly, the signal handler is entered
using the normal userland resume path, so I don't think it requires
special treatment.
For the ptrace() case, it should suffice to set the 'last_cpu' field
to (u32)-1 to indicate that the FPSIMD context should be reloaded from
memory regardless of which CPU the debuggee is restarted on.
Regards,
Ard.
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204143119.GA4627@beef>
Hold your horses. :)
> > > Add a driver for the BCM59056 PMU multi-function device. The driver
> > > initially supports regmap initialization and instantiation of the
> > > voltage regulator device function of the PMU.
> > >
> > > Signed-off-by: Matt Porter <mporter@linaro.org>
> > > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > > ---
> > > drivers/mfd/Kconfig | 8 +++
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > > 4 files changed, 163 insertions(+)
> > > create mode 100644 drivers/mfd/bcm59056.c
> > > create mode 100644 include/linux/mfd/bcm59056.h
<snip>
> > I thought this was a DT only driver? If so, you probably want to use
> > of_match_device() instead.
>
> Correct, I'll use of_match_device()
If you're going to use this ...
<snip>
> > You've gone to the trouble of setting a device version here, but you
> > don't seem to use it?
>
> I'll drop the device version
... then you'll still need this.
> > > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > > + { "bcm59056", BCM59056 },
> > > + { }
> > > +};
> >
> > Ah, I guess this is where id->driver comes from.
> >
> > It's pretty silly that the I2C subsystem demands the presence of this
> > table, despite not using it if an of_device_id table is present.
>
> It does make it very difficult to follow DT enabled I2C client drivers
> :( I'll drop the BCM59056 too.
And I don't think you can drop this, as the I2C subsystem still
insists on it.
> > > +/* chip id */
> > > +#define BCM59056 0
> >
> > Lonely, oh so lonely!
>
> Understood. Will remove.
I think you need to keep this to supply the silly I2C ID table.
I would just omit the '.data = (void *) VERSION' from the
of_match_table until you require it.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/6] BCM59056 PMU regulator support
From: Matt Porter @ 2014-02-04 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204134043.GG13529@lee--X1>
On Tue, Feb 04, 2014 at 01:40:43PM +0000, Lee Jones wrote:
> > The BCM59056 is a multi-function power management unit used with the
> > BCM281xx family of SoCs. This series adds an MFD and voltage regulator
> > driver to support the BCM59056. The bcm28155-ap DT support is updated
> > to enable use of regulators on the otg and sdhci peripherals.
> >
> > Matt Porter (6):
> > i2c: bcm-kona: register with subsys_initcall
> > regulator: add bcm59056 pmu DT binding
> > mfd: add bcm59056 pmu driver
> > regulator: add bcm59056 regulator driver
> > ARM: configs: bcm_defconfig: enable bcm59056 regulator support
> > ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
> >
> > .../devicetree/bindings/regulator/bcm59056.txt | 37 ++
> > arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
> > arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
> > arch/arm/configs/bcm_defconfig | 7 +
> > drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
> > drivers/mfd/Kconfig | 8 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 ++++++
> > drivers/regulator/Kconfig | 8 +
> > drivers/regulator/Makefile | 1 +
> > drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 ++
> > 12 files changed, 873 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
> > create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 drivers/regulator/bcm59056-regulator.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> FYI: Mark's email address is not correct. Not sure where you pulled
> this one up from, but he doesn't have access to it anymore.
Thanks, I already updated (it was a stale .mutt/aliases entry here) it
after the bounces.
-Matt
^ permalink raw reply
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Santosh Shilimkar @ 2014-02-04 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgmTmAOy4SpZU8oxN=0AihcixX5aU1sM_LNe5TiScMaSw@mail.gmail.com>
On Monday 03 February 2014 09:18 PM, Olof Johansson wrote:
> Hi,
>
>
> On Mon, Feb 3, 2014 at 3:28 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> Currently arch specific DMA address translation routines can be enabled
>> using only defines which makes impossible to use them in with
>> multi-platform builds.
>>
>> Hence, introduce arch specific hooks for DMA address translations
>> routines to be compatible with multi-platform builds:
>> dma_addr_t (*arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
>> unsigned long (*arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
>> void* (*arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
>> dma_addr_t (*arch_virt_to_dma)(struct device *dev, void *addr);
>>
>> In case if architecture won't use it - DMA address translation routines
>> will fall-back to existing implementation.
>>
>> Also, modify machines omap1, ks8695, iop13xx to use new DMA hooks.
>
> [...]
>
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index e701a4d..84acc46 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -55,28 +55,16 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>> * functions used internally by the DMA-mapping API to provide DMA
>> * addresses. They must not be used by drivers.
>> */
>> -#ifndef __arch_pfn_to_dma
>> -static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>> -{
>> - return (dma_addr_t)__pfn_to_bus(pfn);
>> -}
>>
>> -static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>> -{
>> - return __bus_to_pfn(addr);
>> -}
>> +extern dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
>> +extern unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
>> +extern void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
>> +extern dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr);
>
> I tend to prefer having these kind of function pointers grouped in a
> struct instead of in the toplevel namespace like this. It allows you
> to use a set_<foo>_ops() interface too instead and reduces
> exposed/exported internals since only the global struct pointer has to
> be exported.
>
agree
[..]
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 5c43ca5..74111bf 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -39,6 +39,35 @@
>>
>> #include "mm.h"
>>
>> +static inline dma_addr_t __pfn_to_dma(struct device *dev, unsigned long pfn)
>> +{
>> + return (dma_addr_t)__pfn_to_bus(pfn);
>> +}
>> +
>> +static inline unsigned long __dma_to_pfn(struct device *dev, dma_addr_t addr)
>> +{
>> + return __bus_to_pfn(addr);
>> +}
>> +
>> +static inline void *__dma_to_virt(struct device *dev, dma_addr_t addr)
>> +{
>> + return (void *)__bus_to_virt((unsigned long)addr);
>> +}
>> +
>> +static inline dma_addr_t __virt_to_dma(struct device *dev, void *addr)
>> +{
>> + return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>> +}
>> +
>> +dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn) = __pfn_to_dma;
>> +EXPORT_SYMBOL(__arch_pfn_to_dma);
>> +unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr) = __dma_to_pfn;
>> +EXPORT_SYMBOL(__arch_dma_to_pfn);
>> +void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr) = __dma_to_virt;
>> +EXPORT_SYMBOL(__arch_dma_to_virt);
>> +dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr) = __virt_to_dma;
>> +EXPORT_SYMBOL(__arch_virt_to_dma);
>
> Independent on whether someone objects to my preference of exporting a
> struct, these (or that struct pointer) should probably be
> EXPORT_SYMBOL_GPL().
>
Sure.
Regards,
Santosh
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204132951.GE13529@lee--X1>
On Tue, Feb 04, 2014 at 01:29:51PM +0000, Lee Jones wrote:
> > Add a driver for the BCM59056 PMU multi-function device. The driver
> > initially supports regmap initialization and instantiation of the
> > voltage regulator device function of the PMU.
> >
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > ---
> > drivers/mfd/Kconfig | 8 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > 4 files changed, 163 insertions(+)
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> <snip>
>
> > +static struct mfd_cell bcm59056s[] = {
> > + {
> > + .name = "bcm59056-pmu",
>
> If you plan to use *->of_node in the PMU driver, which it looks like
> you do, you should set the compatible string here.
Ok. I missed that..I'll split bindings to reflect this as well. There's
an error in that the regulator properties are all defined in the base
compatible of brcm,bcm59056 atm and they'll need to be in
brcm,bcm59056-pmu's binding.
> > + },
> > +};
> > +
> > +static const struct regmap_config bcm59056_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = BCM59056_MAX_REGISTER - 1,
>
> If you've just set this manually i.e. it's not part of an enum table,
> can't you set it a value you don't need to do math on? It's not used
> anywhere else is it?
Yes, I'll update this. It's not used elsewhere.
>
> > + .cache_type = REGCACHE_RBTREE,
> > +};
> > +
> > +static int bcm59056_i2c_probe(struct i2c_client *i2c,
> > + const struct i2c_device_id *id)
> > +{
> > + struct bcm59056 *bcm59056;
> > + int chip_id = id->driver_data;
>
> I thought this was a DT only driver? If so, you probably want to use
> of_match_device() instead.
Correct, I'll use of_match_device()
> > + int ret = 0;
> > +
> > + bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
> > + if (!bcm59056)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(i2c, bcm59056);
> > + bcm59056->dev = &i2c->dev;
> > + bcm59056->i2c_client = i2c;
> > + bcm59056->id = chip_id;
> > +
> > + bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
> > + if (IS_ERR(bcm59056->regmap)) {
> > + ret = PTR_ERR(bcm59056->regmap);
> > + dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = mfd_add_devices(bcm59056->dev, -1,
> > + bcm59056s, ARRAY_SIZE(bcm59056s),
> > + NULL, 0, NULL);
>
> Are you sure you need all of your #includes?
>
> I notice that irqdomain is there, but you don't actually have one?
Right, I'll do a sweep on them. In that particular case, I don't yet
have a need to implement interrupt support so it needs to go.
>
> > + if (ret < 0)
> > + dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
>
> What if we change the name of the function? Probably better to say
> something like "device registration failed" or thelike.
Will do.
>
> > + return ret;
> > +}
> > +
> > +static int bcm59056_i2c_remove(struct i2c_client *i2c)
> > +{
> > + struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
> > +
> > + mfd_remove_devices(bcm59056->dev);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id bcm59056_of_match[] = {
> > + { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
>
> You've gone to the trouble of setting a device version here, but you
> don't seem to use it?
I'll drop the device version
> > + { }
> > +};
> > +
> > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > + { "bcm59056", BCM59056 },
> > + { }
> > +};
>
> Ah, I guess this is where id->driver comes from.
>
> It's pretty silly that the I2C subsystem demands the presence of this
> table, despite not using it if an of_device_id table is present.
It does make it very difficult to follow DT enabled I2C client drivers
:( I'll drop the BCM59056 too.
> > +MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
> > +
> > +static struct i2c_driver bcm59056_i2c_driver = {
> > + .driver = {
> > + .name = "bcm59056",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(bcm59056_of_match),
>
> No need to use of_match_ptr() here.
Will remove.
> > + },
> > + .probe = bcm59056_i2c_probe,
> > + .remove = bcm59056_i2c_remove,
> > + .id_table = bcm59056_i2c_id,
>
> *grumble*
:) Yes, unavoidable for now.
> > +};
> > +
> > +static int __init bcm59056_init(void)
> > +{
> > + return i2c_add_driver(&bcm59056_i2c_driver);
> > +}
> > +subsys_initcall(bcm59056_init);
>
> Really? :(
>
> Maybe you'll want to comment this, in case people do not know the back
> ground and attempts to clean it up.
I'll add a comment. This is the old problem of needing regulators really
early. It's exasperated by the fact that the USB gadget framework
drivers do not use driver probing. This means that they can not be
deferred after i2c/mfd/regulator init...the problem is particularly
noticeable when building in a gadget driver for nfsroot purposes.
Because of this I have the regulator, MFD, and i2c drivers all using
subsys_initcall() in this series. FWIW, there's some discussion about
how to resolve the USB gadget driver case but it's going to take a
while.
> > +static void __exit bcm59056_exit(void)
> > +{
> > + i2c_del_driver(&bcm59056_i2c_driver);
> > +}
> > +module_exit(bcm59056_exit);
>
> <snip>
>
> > +/* chip id */
> > +#define BCM59056 0
>
> Lonely, oh so lonely!
Understood. Will remove.
> > +/* max register address */
> > +#define BCM59056_MAX_REGISTER 0xe8
>
> Don't you have a table of registers which you care about?
I placed the register defs that I actually use in the regulator driver
itself since that is the only place they are used. I notice most MFD
drivers centralize this in linux/mfd/*.h. However, generally chunk
of register defs are only used in one subdriver and not shared. If
it's preferred to move all register defs centrally I can do that.
> > +/* bcm59056 chip access */
>
> Superfluous comment? Don't we all know what these containers do?
Indeed, will remove.
Thanks for reviewing.
-Matt
> > +struct bcm59056 {
> > + struct device *dev;
> > + struct i2c_client *i2c_client;
> > + struct regmap *regmap;
> > + unsigned int id;
> > +};
> > +
> > +#endif /* __LINUX_MFD_BCM59056_H */
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC/RFT 2/2] ARM: keystone: Install hooks for dma address translation routines
From: Santosh Shilimkar @ 2014-02-04 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgzsx3gE6cT-nMTJfnO1T5pvfTr8HA6tVGv8svF_kCYjg@mail.gmail.com>
On Monday 03 February 2014 09:05 PM, Olof Johansson wrote:
> Hi,
>
> On Mon, Feb 3, 2014 at 3:28 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> Keystone platforms have their physical memory mapped at an address
>> outside the 32-bit physical range. A Keystone machine with 16G of RAM
>> would find its memory at 0x0800000000 - 0x0bffffffff.
>> The system interconnect allows to perform DMA transfers from first 2G of
>> physical memory (0x08 0000 0000 to 08 7FFF FFFF) which aliased in
>> hardware to the 32-bit addressable space (0x80000000 - 0xffffffff),
>> because DMA HW supports only 32-bits addressing.
>>
>> Hence, add arch hooks for dma address translation routines.
>>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Olof Johansson <olof@lixom.net>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-keystone/keystone.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
>> index 1b43a27..54dae03 100644
>> --- a/arch/arm/mach-keystone/keystone.c
>> +++ b/arch/arm/mach-keystone/keystone.c
>> @@ -14,6 +14,7 @@
>> #include <linux/init.h>
>> #include <linux/of_platform.h>
>> #include <linux/of_address.h>
>> +#include <linux/dma-mapping.h>
>>
>> #include <asm/setup.h>
>> #include <asm/mach/map.h>
>> @@ -53,6 +54,28 @@ static phys_addr_t keystone_virt_to_idmap(unsigned long x)
>> return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
>> }
>>
>> +static unsigned long keystone_dma_pfn_offset __read_mostly;
>> +
>> +static dma_addr_t keystone_pfn_to_dma(struct device *dev, unsigned long pfn)
>> +{
>> + return PFN_PHYS(pfn - keystone_dma_pfn_offset);
>> +}
>> +
>> +static unsigned long keystone_dma_to_pfn(struct device *dev, dma_addr_t addr)
>> +{
>> + return PFN_DOWN(addr) + keystone_dma_pfn_offset;
>> +}
>> +
>> +static void *keystone_dma_to_virt(struct device *dev, dma_addr_t addr)
>> +{
>> + return phys_to_virt(addr + PFN_PHYS(keystone_dma_pfn_offset));
>> +}
>> +
>> +static dma_addr_t keystone_virt_to_dma(struct device *dev, void *addr)
>> +{
>> + return virt_to_phys(addr) - PFN_PHYS(keystone_dma_pfn_offset);
>> +}
>> +
>> static void __init keystone_init_meminfo(void)
>> {
>> bool lpae = IS_ENABLED(CONFIG_ARM_LPAE);
>> @@ -89,6 +112,14 @@ static void __init keystone_init_meminfo(void)
>> /* Populate the arch idmap hook */
>> arch_virt_to_idmap = keystone_virt_to_idmap;
>>
>> + /* Populate the arch DMA hooks */
>> + keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
>> + KEYSTONE_LOW_PHYS_START);
>> + __arch_pfn_to_dma = keystone_pfn_to_dma;
>> + __arch_dma_to_pfn = keystone_dma_to_pfn;
>> + __arch_dma_to_virt = keystone_dma_to_virt;
>> + __arch_virt_to_dma = keystone_virt_to_dma;
>
> Is this truly a static window, or is it going through an IOMMU that
> just happens to have an identity mapping setup per default?
>
Its true physical static window hardwired in Hardware. No IOMMU
involvement.
> PPC servers use "ibm,dma-window" to describe the assigned dma address
> space for busses/devices, but the window itself doesn't contain any
> information about the physical address mapping (since it goes through
> an iommu after that). It likely doesn't fit this particular use case,
> but it's something we should look at as a base in case we need to
> start looking at bindings for this instead of coding it per SoC. We'll
> know more once we've seen what a few of the implementations out there
> are.
>
Understood.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
From: Rob Herring @ 2014-02-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506890-7335-3-git-send-email-thomas.ab@samsung.com>
On Tue, Feb 4, 2014 at 3:41 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Certain CPUs or devices can support optional boost operating modes. Add a new
> binding to list OPPs to be additionally made available in boost operating modes.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> Documentation/devicetree/bindings/power/opp.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
> index 74499e5..4df5cca 100644
> --- a/Documentation/devicetree/bindings/power/opp.txt
> +++ b/Documentation/devicetree/bindings/power/opp.txt
> @@ -10,6 +10,10 @@ Properties:
> freq: clock frequency in kHz
> vol: voltage in microvolt
>
> +Optional Properties:
> +- boost-opp: Similar to "operating-points" property but usable only in
> + optional boost operating modes.
> +
> Examples:
>
> cpu at 0 {
> @@ -22,4 +26,9 @@ cpu at 0 {
> 396000 950000
> 198000 850000
> >;
> + boost-opp = <
> + /* kHz uV */
> + 1500000 1350000
> + 1400000 1285000
> + >;
This looks like an example of needing to add more properties to the
OPP table. There are ongoing discussions on how to extend OPP table
and map to C states. This should be part of that discussion.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: i.MX51 babbage: Support diagnostic LED
From: Liu Ying @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
The D25 LED controlled by gpio on the i.MX51 babbage
board is a diagnostic LED according to the board design.
This patch adds the relevant device tree nodes to the
i.MX51 babbage device tree file to support this LED.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
arch/arm/boot/dts/imx51-babbage.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index be1407c..8d6a74b 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -81,6 +81,17 @@
};
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pin_gpio2_6>;
+
+ led-diagnostic {
+ label = "diagnostic";
+ gpios = <&gpio2 6 0>;
+ };
+ };
+
sound {
compatible = "fsl,imx51-babbage-sgtl5000",
"fsl,imx-audio-sgtl5000";
@@ -280,6 +291,12 @@
MX51_PAD_CSPI1_RDY__GPIO4_26 0x80000000
>;
};
+
+ led_pin_gpio2_6: led_gpio2_6 {
+ fsl,pins = <
+ MX51_PAD_EIM_D22__GPIO2_6 0x80000000
+ >;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Rob Herring @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 4, 2014 at 3:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
>> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
>> without clearly specifying exactly how PCI is suppose to work is
>> completely bonkers.
>>
>> What is needed is a spec that says:
>> 1) Here is how you generate config TLPs. A MMIO region that
>> conforms to the already specified x86 ECAM would
>> be perfect
>> 2) Here is a dword by dword break down of the entire config space in
>> a SOC. Here is where a on-board AHCI controller must show up in
>> config space. Here is how an external PCI-E port must show
>> up. Etc. Most of this is already specified, but it clearly needs
>> to be layed out explicitly for ARM SOCs to actually follow it.
>> 3) Here is how you specify the aperture(s) associated with PCI BAR's
>> and bridge windows in config space. And yes: The CONFIG SPACE
>> BARS MUST WORK.
>> 4) Here is how MSI works, these are the values you put in the
>> address/data and here is how you collect the interrupt.
>> 5) Here is how Legacy INTx must be mapped into the GIC.
>>
>> This is what x86 does, and they have been doing it well for 10
>> years. If you want to play in the server game you have to properly
>> implement PCI.
>
> I'm pretty sure the authors of the SBSA actually thought that was
> what they wrote, by referring to external specifications (pci-3.0,
> ehci, ahci, ...). However, it seems they were either foolish enough
> to believe that hardware designers would follow these specs, or
> they were intentionally misled and got talked into putting ambiguous
> terminology in because there were already hardware designs that
> are not exactly in line with the spirit of the SBSA but can be
> argued to be conforming to the text for a lax interpretation.
>
> I think EHCI is a much better example than PCI here, because the
> spec has exactly one line to say about it, where it spends a whole
> chapter on PCI.
>
> Here is how a sane person would read SBSA to create a compliant
> implementation:
s/sane/software/
>
> I have to use EHCI version 1.1 to provide USB-2.0 support. EHCI
> is a PCI device, so I'll put it behind a PCIe port that complies
> to the PCIe section of the SBSA. Since EHCI by itself only provides
> high-speed USB, and USB-2.0 mandates I provide low-speed and
> full-speed as well, I have to add a USB hub device. It would have
> been easier to just use OHCI for these, but SBSA says I can't.
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
> look exactly as if it was on an external card, I just have to
> ensure the boot loader correctly sets up the clocks and the phy
> before an SBSA compliant OS gets loaded, all runtime power
> management will get handled through the EHCI-1.1 energy-efficiency
> extensions.
>
> Here is how a crazy person would read the same sentence in the SBSA:
s/crazy/hardware/
>
> I have an IP block that implements the EHCI register set, that
> should be good enough. It's not a fast device, so I can put it
> on a non-coherent bus. Since the SoC will be used for networking,
> I'll put the registers into big-endian configuration to make it
> easier for the OS to access. I'm not allowed to have USB-1.1
> according to SBSA, so I can get away without a hub or an extra
> OHCI. I can't support MSI because it's not a PCI device, and
> the GIC is pretty full, so I'll just connect the IRQ line to
> the GPIO controller. In order to do better power management,
> I'll design a fancy PHY that the device driver will manage
> for implementing autosuspend. I should also give the OS
> fine-grained control over the clocks, but it will have to share
> the clock domain with the other devices on the same edge of the
> chip. The EHCI device is not part of PCI, which measn I don't
> have to use the standard SMMU. However, my EHCI implementation
> can only do 32-bit DMA, and I'll have to design my own IOMMU
> to let it access the entire memory range. USB-OTG is a great
> feature and we already paid for having this in our EHCI
> implementation, better make sure it comes up in endpoint mode
> after waking up from power saving.
My money is on the latter. I think non-PCI implementations of xHCI
interfaces will be common. This was certainly the case at Calxeda in
what was believed to be a SBSA compliant SOC. However, I think PCI
device or not is the least of the issues and all the other examples
you list are the difficult ones to deal with.
Rob
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0A7F5.6070201@overkiz.com>
Hello, Mike,
Please do not take this patch: the work of JJ to fix the prog clk
prepare bug
will remove the irq handling from the prog clk driver, as a result, we won't
have to request the irq anymore.
Sorry for the inconvenience.
Best Regards,
Boris
On 04/02/2014 09:42, Boris BREZILLON wrote:
> Hello JJ,
>
> Sorry for the noise (I added Mike in the CC list).
>
> BTW, thanks for fixing this bug.
>
> Mike, could you take this bug fix for the next 3.14 release ?
>
> Best Regards,
>
> Boris
>
> On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
>> The name provided to request_irq() must be valid until the irq is
>> released.
>> This patch stores the name in the internal data structure.
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>> drivers/clk/at91/clk-programmable.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/at91/clk-programmable.c
>> b/drivers/clk/at91/clk-programmable.c
>> index 8e242c7..799b75c 100644
>> --- a/drivers/clk/at91/clk-programmable.c
>> +++ b/drivers/clk/at91/clk-programmable.c
>> @@ -44,6 +44,7 @@ struct clk_programmable {
>> u8 css;
>> u8 pres;
>> u8 slckmck;
>> + char irq_name[11];
>> const struct clk_programmable_layout *layout;
>> };
>> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc
>> *pmc, unsigned int irq,
>> struct clk_programmable *prog;
>> struct clk *clk = NULL;
>> struct clk_init_data init;
>> - char irq_name[11];
>> if (id > PROG_ID_MAX)
>> return ERR_PTR(-EINVAL);
>> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc
>> *pmc, unsigned int irq,
>> prog->irq = irq;
>> init_waitqueue_head(&prog->wait);
>> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
>> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
>> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
>> ret = request_irq(prog->irq, clk_programmable_irq_handler,
>> - IRQF_TRIGGER_HIGH, irq_name, prog);
>> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
>> if (ret)
>> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH 0/3] clk: at91: various fixes and improvements
From: Boris BREZILLON @ 2014-02-04 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-1-git-send-email-b.brezillon@overkiz.com>
Hello, Mike,
Please do not take this series: the prog clk driver is still buggy (this was
reported by Jean-Jacques Hiblot).
Jean-Jacques is preparing a new series to fix these bugs, and I'll rebase
patch 2 and 3 of this series on top of his work.
Sorry for the inconvenience.
Best Regards,
Boris
On 03/02/2014 12:25, Boris BREZILLON wrote:
> Hello Mike,
>
> This series fixes a bug in the prog clk prepare function (the platform hangs
> when preparing a prog clk).
>
> It also implements the determine_rate callback for these prog clks and allow
> system clk to propagate the rate change to its parent.
>
> These modifications are needed to get the atmel_wm8904 driver working (this
> driver make use of prog clks), and if possible, should be merged in the next
> 3.14 release (at least the first patch of this series).
>
> Let me know if this is not possible.
>
> Thanks.
>
> Best Regards,
>
> Boris
>
> Boris BREZILLON (3):
> clk: at91: fix programmable clk irq handling
> clk: at91: replace prog clk round_rate with determine_rate
> clk: at91: propagate rate change on system clks
>
> drivers/clk/at91/clk-programmable.c | 61 ++++++++++++++++++-----------------
> drivers/clk/at91/clk-system.c | 3 +-
> 2 files changed, 34 insertions(+), 30 deletions(-)
>
^ 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