* [PATCH v2 14/15] charger: max14577: Configure battery-dependent settings from DTS
From: Lee Jones @ 2014-02-10 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391767487-10017-15-git-send-email-k.kozlowski@samsung.com>
> Remove hard-coded values for:
> - Fast Charge current,
> - End Of Charge current,
> - Fast Charge timer,
> - Overvoltage Protection Threshold,
> - Battery Constant Voltage,
> and use DTS to configure them. This allows using the max14577 charger
> driver with different batteries.
>
> Now the charger driver requires valid configuration data from DTS. In
> case of wrong configuration data it fails during probe. Patch adds
> of_compatible to the charger mfd cell in MFD driver core.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Jenny Tc <jenny.tc@intel.com>
> ---
> drivers/mfd/max14577.c | 5 +-
> drivers/power/max14577_charger.c | 234 +++++++++++++++++++++++++++++-----
> include/linux/mfd/max14577-private.h | 10 ++
> include/linux/mfd/max14577.h | 8 ++
> 4 files changed, 227 insertions(+), 30 deletions(-)
<snip>
> diff --git a/include/linux/mfd/max14577-private.h b/include/linux/mfd/max14577-private.h
> index a8cd7de3526a..50cf70bec4d4 100644
> --- a/include/linux/mfd/max14577-private.h
> +++ b/include/linux/mfd/max14577-private.h
> @@ -269,6 +269,16 @@ enum maxim_muic_charger_type {
> #define MAX77836_CHARGER_CURRENT_LIMIT_HIGH_STEP 25000U
> #define MAX77836_CHARGER_CURRENT_LIMIT_MAX 475000U
>
> +/* MAX14577 charger End-Of-Charge current limits (as in MAXIM_CHGCTRL5 register), uA */
Too many chars. Didn't checkpatch.pl complain about this?
> +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN 50000U
> +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_STEP 10000U
> +#define MAX14577_CHARGER_EOC_CURRENT_LIMIT_MAX 200000U
> +
> +/* MAX14577/MAX77836 Battery Constant Voltage (as in MAXIM_CHGCTRL3
> register), uV */
Same here
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCHv2 0/4] Add DT support for fixed PHYs
From: Thomas Petazzoni @ 2014-02-10 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9NwWfutp6MitSuG-LNH=0Y0ffewuSawLXJOe2JUL7=tz7BWQ@mail.gmail.com>
Dear Christian Gmeiner,
On Mon, 10 Feb 2014 11:30:30 +0100, Christian Gmeiner wrote:
> >> +1 for the general idea. This really looks good now. I've not much more
> >> to say. Maybe someone from the devicetree corner has a few words for the
> >> binding?
> >>
> >
> > I tested the whole series with an I.MX6D board with the FEC driver:
> > fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY]
> > (mii_bus:phy_addr=fixed-0:00, irq=-1)
> >
> > For me binding looks nice and I hope to see this patch series in 3.13.
> >
> > Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
>
> Is there any update on this patch series?
I'll try to send a new version in the next few days. It's still part of
my TODO list.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 02/03] pinctrl: sh-pfc: r8a7790: Break out USB0 OVC/VBUS
From: Laurent Pinchart @ 2014-02-10 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaOeA1FSLxkqYy8e0vzCHmS4JAVZrAiq6wV0sukN8+atg@mail.gmail.com>
Hi Linus,
On Monday 10 February 2014 10:17:00 Linus Walleij wrote:
> On Fri, Feb 7, 2014 at 1:36 AM, Laurent Pinchart wrote:
> > I was thinking about letting Linus pick up the PFC patches again now that
> > the flood is over. Of course, if it can help, I can still pick the
> > patches up and submit pull requests to Linus.
> >
> > Linus, what's your opinion on this ? Would you rather pick the patches
> > directly after I've acked them, or process pull requests ?
>
> As long as it's reasonable traffic I'll take it. :-)
>
> I'll queue this one then, I guess only patch 2/3?
That's correct. Thank you.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Tomi Valkeinen @ 2014-02-10 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387624080-15312-1-git-send-email-shc_work@mail.ru>
On 21/12/13 13:08, Alexander Shiyan wrote:
> This patch replaces custom lcd_power() callback with
> regulator API over LCD class.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> .../devicetree/bindings/video/fsl,imx-fb.txt | 1 +
> arch/arm/mach-imx/mach-mx27ads.c | 55 +++++++++++++++--
> drivers/video/imxfb.c | 71 +++++++++++++++++++---
> include/linux/platform_data/video-imxfb.h | 1 -
> 4 files changed, 114 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> index 46da08d..e6b1ee9 100644
> --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -15,6 +15,7 @@ Required nodes:
> - fsl,pcr: LCDC PCR value
>
> Optional properties:
> +- lcd-supply: Regulator for LCD supply voltage.
> - fsl,dmacr: DMA Control Register value. This is optional. By default, the
> register is not modified as recommended by the datasheet.
> - fsl,lscr1: LCDC Sharp Configuration Register value.
> diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
> index 9821b824..a7a4a9c 100644
> --- a/arch/arm/mach-imx/mach-mx27ads.c
> +++ b/arch/arm/mach-imx/mach-mx27ads.c
> @@ -21,6 +21,10 @@
> #include <linux/mtd/physmap.h>
> #include <linux/i2c.h>
> #include <linux/irq.h>
> +
> +#include <linux/regulator/fixed.h>
> +#include <linux/regulator/machine.h>
> +
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/time.h>
> @@ -195,14 +199,58 @@ static const struct imxi2c_platform_data mx27ads_i2c1_data __initconst = {
> static struct i2c_board_info mx27ads_i2c_devices[] = {
> };
>
> -void lcd_power(int on)
> +static void vgpio_set(struct gpio_chip *chip, unsigned offset, int value)
> {
> - if (on)
> + if (value)
> __raw_writew(PBC_BCTRL1_LCDON, PBC_BCTRL1_SET_REG);
> else
> __raw_writew(PBC_BCTRL1_LCDON, PBC_BCTRL1_CLEAR_REG);
> }
>
> +static int vgpio_dir_out(struct gpio_chip *chip, unsigned offset, int value)
> +{
> + return 0;
> +}
> +
> +#define MX27ADS_LCD_GPIO (6 * 32)
> +
> +static struct regulator_consumer_supply mx27ads_lcd_regulator_consumer =
> + REGULATOR_SUPPLY("lcd", "imx-fb.0");
> +
> +static struct regulator_init_data mx27ads_lcd_regulator_init_data = {
> + .constraints = {
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> +},
> + .consumer_supplies = &mx27ads_lcd_regulator_consumer,
> + .num_consumer_supplies = 1,
> +};
> +
> +static struct fixed_voltage_config mx27ads_lcd_regulator_pdata = {
> + .supply_name = "LCD",
> + .microvolts = 3300000,
> + .gpio = MX27ADS_LCD_GPIO,
> + .init_data = &mx27ads_lcd_regulator_init_data,
> +};
> +
> +static void __init mx27ads_regulator_init(void)
> +{
> + struct gpio_chip *vchip;
> +
> + vchip = kzalloc(sizeof(*vchip), GFP_KERNEL);
> + vchip->owner = THIS_MODULE;
> + vchip->label = "LCD";
> + vchip->base = MX27ADS_LCD_GPIO;
> + vchip->ngpio = 1;
> + vchip->direction_output = vgpio_dir_out;
> + vchip->set = vgpio_set;
> + gpiochip_add(vchip);
> +
> + platform_device_register_data(&platform_bus, "reg-fixed-voltage",
> + PLATFORM_DEVID_AUTO,
> + &mx27ads_lcd_regulator_pdata,
> + sizeof(mx27ads_lcd_regulator_pdata));
> +}
> +
Hmm, isn't all this something that should be in the board's .dts?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/7e251ede/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/15] mfd: max77836: Add max77836 support to max14577 driver
From: Lee Jones @ 2014-02-10 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391767487-10017-9-git-send-email-k.kozlowski@samsung.com>
> Add Maxim 77836 support to max14577 driver. The chipsets have same MUIC
> component so the extcon, charger and regulators are almost the same. The
> max77836 however has also PMIC and Fuel Gauge.
>
> The MAX77836 uses three I2C slave addresses and has additional interrupts
> (related to PMIC and Fuel Gauge). It has also Interrupt Source register,
> just like MAX77686 and MAX77693.
>
> The MAX77836 PMIC's TOPSYS and INTSRC interrupts are reported in the
> PMIC block. The PMIC block has different I2C slave address and uses own
> regmap so another regmap_irq_chip is needed.
>
> Since we have two regmap_irq_chip, use shared interrupts on MAX77836.
>
> This patch adds additional defines and functions to the max14577 MFD core
> driver so the driver will handle both chipsets. Also this patch replaces
> "0x1 << N" with BIT(N) in defines for register masks.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/mfd/max14577.c | 217 ++++++++++++++++++++++++++++++++--
> include/linux/mfd/max14577-private.h | 175 +++++++++++++++++++--------
> include/linux/mfd/max14577.h | 7 +-
> 3 files changed, 341 insertions(+), 58 deletions(-)
Much better, thanks.
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 13/15] regulator/mfd: max14577: Export symbols for calculating charger current
From: Lee Jones @ 2014-02-10 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391767487-10017-14-git-send-email-k.kozlowski@samsung.com>
> This patch prepares for changing the max14577 charger driver to allow
> configuring battery-dependent settings from DTS.
>
> The patch moves from regulator driver to MFD core driver and exports:
> - function for calculating register value for charger's current;
> - table of limits for chargers (MAX14577, MAX77836).
>
> Previously they were used only by the max14577 regulator driver. In next
> patch the charger driver will use them as well. Exporting them will
> reduce unnecessary code duplication.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/mfd/max14577.c | 95 ++++++++++++++++++++++++++++++++++
> drivers/regulator/max14577.c | 80 +++-------------------------
> include/linux/mfd/max14577-private.h | 22 ++++----
> include/linux/mfd/max14577.h | 23 ++++++++
> 4 files changed, 135 insertions(+), 85 deletions(-)
Applied, with Mark's Ack.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] dt/bindings: update fsl-fec regarding compatible and clocks
From: Shawn Guo @ 2014-02-10 11:50 UTC (permalink / raw)
To: linux-arm-kernel
Update fsl-fec to explicitly list the supported compatible strings
and add missing 'clocks' and 'clock-names' properties. It does not
change anything about how kernel drive works. Instead, it just reflects
how kernel driver works today.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Documentation/devicetree/bindings/net/fsl-fec.txt | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index 845ff84..3ebd395 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -1,9 +1,26 @@
* Freescale Fast Ethernet Controller (FEC)
Required properties:
-- compatible : Should be "fsl,<soc>-fec"
+- compatible : Should contain one of the following:
+ "fsl,imx25-fec"
+ "fsl,imx27-fec"
+ "fsl,imx28-fec"
+ "fsl,imx6q-fec"
+ "fsl,mvf600-fec"
- reg : Address and length of the register set for the device
- interrupts : Should contain fec interrupt
+- clocks: phandle to the clocks feeding the FEC controller and phy. The
+ following two are required:
+ - "ipg": the peripheral access clock
+ - "ahb": the bus clock for MAC
+ The following two are optional:
+ - "ptp": the sampling clock for PTP (IEEE 1588). On SoC like i.MX6Q,
+ the clock could come from either the internal clock control module
+ or external oscillator via pad depending on board design.
+ - "enet_out": the phy reference clock provided by SoC via pad, which
+ is available on SoC like i.MX28.
+- clock-names: Must contain the clock names described just above
+
- phy-mode : String, operation mode of the PHY interface.
Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
"rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ARM: Kirkwood: Add support for many Synology NAS devices
From: Ian Campbell @ 2014-02-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206160126.GH29860@lunn.ch>
On Thu, 2014-02-06 at 17:01 +0100, Andrew Lunn wrote:
> Synology seem to build there devices like lego. They have two
> different RTC blocks. They have three different fan alarm blocks, four
> different led blocks, etc. And to build a product, the just select a
> group of blocks and put them together.
>
> The board setup code which Ben Peddell wrote has a somewhat similar
> structure:
>
> http://klightspeed.killerwolves.net/synology/linux-3.4-synology-0.1.patch
>
> It has a set of functions which add platform devices. And a table
> driven piece of code which based on the product name calls these
> functions to add the needed platform devices. Take a look at the table
> to get a better idea of the re-use factor of the blocks.
>
> In this DT version, i have a dtsi file for each function, and a dti
> file for each table entry.
At least some other platforms deal with this by having a baseline dtsi
where most things have status="disabled" and then a per-board .dts file
which contains status="okay" and perhaps any specific pin bindings etc.
See arch/arm/boot/dts/sun?i* for an example of this approach.
Ian.
^ permalink raw reply
* [PATCH 14/28] Remove MACH_SMDKC210
From: Mark Brown @ 2014-02-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-15-git-send-email-richard@nod.at>
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
Please fix whatever script you're using to generate your mails, it's
generating corrupt headers. Please also use subject lines consistent
with the rest of the subsystem - between the two I very nearly just
deleted this unread, it's only Paul's mail that made me look.
> config SND_SOC_SAMSUNG_SMDK_WM9713
> tristate "SoC AC97 Audio support for SMDK with WM9713"
> - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
> + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
Like I said to Paul this isn't fixing the actual issue - think about why
the symbol was there in the first place and why it was removed. There
is a problem here but this would make it less likely that it would be
properly fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/45e54c4b/attachment.sig>
^ permalink raw reply
* [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-10 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dac5ec28-3a6d-428f-8ab6-c8f2bb53168f@googlegroups.com>
Hi
> > + (cmd->opcode == 5 || cmd->opcode == 52))
> Aren't these the ones defined in linux/mmc/sdio.h:
> 5 - SD_IO_SEND_OP_COND
> 52 - SD_IO_RW_DIRECT
Yes. They are...
Changed that.
Also I removed the camel cases and the defines within the struct definition.
> > +struct sunxi_mmc_clk_dly {
> > + u32 mode;
> > + u32 oclk_dly;
> > + u32 sclk_dly;
> Do these members have to be u32? They all seem to be smaller than 10.
Yes. Because of situations where it gets used in bit operations, and shorter
types mess things up and prevent the driver from working ;-)
cheer
david
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/8a8707bf/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210085305.641e6de5@amdc2363>
On 10/02/14 07:53, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
>
>> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
>>> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
>>> <Sudeep.Holla@arm.com> wrote:
>>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>>> <Sudeep.Holla@arm.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>>> userspace(list of frequencies and the boost parameters are
>>>>>> exposed through sysfs)
>>>>>
>>>>> That will be a different problem -> as currently every single
>>>>> frequency in the cpufreq list has ability to be marked as boost
>>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>>> the userspace :D
>>>>>
>>>>
>>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>>> gives the list of frequencies based on the state of the boost
>>>> feature at anytime.
>>>>
>>>> Intuitively the list without boost shouldn't have any frequency
>>>> above the range when it's enabled :), that's what I was referring
>>>> to. So I am not talking about any issue with user-space
>>>> maintenance.
>>> Fair enough - but i still think it has nothing to do with dt binding
>>> itself -> and i think the discussion we've had should be good for
>>> the binding provided in this patch.. I hope.. if documentation
>>> needs a bit of better explanation to prevent a repeat of the same
>>> discussion at a later point of time, now might be a good time to
>>> add it in.
>>
Nishanth, though I am not convinced that it should be list, since you have a
valid point that this should not prevent in having this feature, I am fine with
the list.
>> The term boost and over-clocking have been described in the bindings
>> document as being the same. Since the term over-clocking refers to
>> running a CPU beyond normal operating frequencies, I tend to agree
>> with Sudeep that it is not intuitive if a normal operating frequency
>> is greater than a boost mode frequency.
>>
>> Otherwise, when userspace does "echo 1 >
>> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
>> think the original intent of boost mode patches was to allow CPU to
>> operate at frequencies greater than the normal operating frequencies.
>>
>> Lukasz, how would you want this to be handled?
>
> Please consider an example:
>
> normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
> [1]
> boost-freqs: 1700000, 1600000, 1500000. [2]
>
> All those freqs shall be represented as OPPs freq and voltage tuple.
>
> Best would be to specify all the boost-freqs as:
> boost-freqs = <1700000 1600000 1500000> to be prepared for future
> quirks or problems (or special cases which might show up latter).
> If anybody can foresee any potential threads - like platform on which
> boost freqs are 1700000 and 1500000, but not 1600000, then please share
> this information.
>
If that's the case then why should it be included in the list of OPPs.
I know Nishanth had a valid point in other thread previously(like including
SoC.dtsi having OPPs in platform files), but that's different problem.
> However, I think that it would be also acceptable to specify only:
> boost-freq = <1500000> and mark all freqs greater or equal to it as
> CPUFREQ_BOOST_FREQ.
>
> If there aren't any potential problems, then I think the second option
> would be a good solution (we would have only one BOOST attribute stored
> at CPUs DTS node).
>
Yes I prefer this to keep it simple and as per the definition of overclocking
or turbo boost in hardware terms if possible.
Just another thought, not sure how much this is true for real platforms, sharing
it anyway. IIUC these boost frequencies have certain constraints like thermal
and can't be sustained all the processors for long time.
So does it make sense to specify normal max frequency instead of boost-frequency
which by definition would be: "The maximum frequency that all processors are can
sustain simultaneously without any thermal constraints".
Ignore this if this is not the definition of boost on real platforms.
Regards,
Sudeep
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Will Deacon @ 2014-02-10 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F892C8.80508@st.com>
On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
> On 02/07/2014 06:09 PM, Will Deacon wrote:
> > On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> >> index 4636d56..ef15709 100644
> >> --- a/arch/arm/kernel/traps.c
> >> +++ b/arch/arm/kernel/traps.c
> >> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> >>
> >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> >> +
> >> + /* Enable imprecise aborts */
> >> + local_abt_enable();
> > Surely we want to enable this as early as possible? Now, putting this into
> > head.S is ugly, as it duplicating it across all the proc*.S files, so why
> > not setup_arch?
> Sorry, I'm not sure to understand your last comment.
> At least, I need it enabled before probing drivers (PCIe bus)
> I've added imprecise abort enable code in traps.c, following Russel
> King's advice, please see:
> http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
> As abort bit is local to a cpu, i've also added it in smp.c, but this
> may not be the right place ?
>
> Please elaborate,
I was just suggesting that we move your local_abt_enable() call to
setup_arch, since that's called before early_trap_init on the primary CPU.
Will
^ permalink raw reply
* [PATCH v2] sched_clock: Prevent callers from seeing half-updated data
From: Will Deacon @ 2014-02-10 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391812138-15492-1-git-send-email-sboyd@codeaurora.org>
On Fri, Feb 07, 2014 at 10:28:58PM +0000, Stephen Boyd wrote:
> If two sched_clock sources are registered we may end up in a
> situation where a call to sched_clock() may be accessing the
> epoch cycle count for the old counter and the cycle count for the
> new counter. This can lead to confusing results where
> sched_clock() values jump and then are reset to 0 (due to the way
> the registration function forces the epoch_ns to be 0). Fix this
> by reorganizing the registration function to hold the seqlock for
> as short a time as possible while we update the clock_data
> structure for a new counter. We also put any accumulated time
> into epoch_ns instead of resetting the time to 0 so that the clock
> doesn't reset after each successful registration.
>
> Reported-by: Will Deacon <will.deacon@arm.com>
> Cc: Josh Cartwright <joshc@codeaurora.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes since v1:
> * Put elapsed time into epoch_ns
Well, this certainly fixes the dmesg prints and the system seems ok once
it's booted:
Tested-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 05/17] mmc: mmci: Put the device into low power state at system suspend
From: Ulf Hansson @ 2014-02-10 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8738jyu1h9.fsf@paris.lan>
On 4 February 2014 20:22, Kevin Hilman <khilman@linaro.org> wrote:
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
>> Due to the available runtime PM callbacks, we are now able to put our
>> device into low power state at system suspend.
>>
>> Earlier we could not accomplish this without trusting a power domain
>> for the device to take care of it. Now we are able to cope with
>> scenarios both with and without a power domain.
>>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> drivers/mmc/host/mmci.c | 45 +++++++++++++++++++++++++--------------------
>> 1 file changed, 25 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index c88da1c..074e0cb 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1723,33 +1723,38 @@ static int mmci_remove(struct amba_device *dev)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_SUSPEND
>> -static int mmci_suspend(struct device *dev)
>> +#ifdef CONFIG_PM_SLEEP
>> +static int mmci_suspend_late(struct device *dev)
>> {
>> - struct amba_device *adev = to_amba_device(dev);
>> - struct mmc_host *mmc = amba_get_drvdata(adev);
>> + int ret = 0;
>>
>> - if (mmc) {
>> - struct mmci_host *host = mmc_priv(mmc);
>> - pm_runtime_get_sync(dev);
>> - writel(0, host->base + MMCIMASK0);
>> - }
>> + if (pm_runtime_status_suspended(dev))
>> + return 0;
>>
>> - return 0;
>> + if (dev->pm_domain && dev->pm_domain->ops.runtime_suspend)
>> + ret = dev->pm_domain->ops.runtime_suspend(dev);
>> + else
>> + ret = dev->bus->pm->runtime_suspend(dev);
>> +
>> + if (!ret)
>> + pm_runtime_set_suspended(dev);
>
> Isn't this basically open-coding pm_runtime_suspend()...
It is similar, but with once big difference.
Since the PM core prevents pm_runtime_suspend() from invoking our
->runtime_suspend callback during system suspend (it does so by
invoking pm_runtime_get_sync() before starting the suspend sequence),
we then need to make the driver handle that by itself.
>
>> + return ret;
>> }
>>
>> -static int mmci_resume(struct device *dev)
>> +static int mmci_resume_early(struct device *dev)
>> {
>> - struct amba_device *adev = to_amba_device(dev);
>> - struct mmc_host *mmc = amba_get_drvdata(adev);
>> + int ret = 0;
>>
>> - if (mmc) {
>> - struct mmci_host *host = mmc_priv(mmc);
>> - writel(MCI_IRQENABLE, host->base + MMCIMASK0);
>> - pm_runtime_put(dev);
>> - }
>> + if (pm_runtime_status_suspended(dev))
>> + return 0;
>>
>> - return 0;
>> + if (dev->pm_domain && dev->pm_domain->ops.runtime_resume)
>> + ret = dev->pm_domain->ops.runtime_resume(dev);
>> + else
>> + ret = dev->bus->pm->runtime_resume(dev);
>> +
>> + return ret;
>
> ...and this is pm_runtime_resume()? (though both terribly simplified.)
Correct, but again with a big difference. See comment above.
>
> This is starting to show that building with PM_SLEEP but not PM_RUNTIME
> is going to force open-coding a lot of stuff that the runtime PM
> framework already provides. So either we need some helper functions so
> we're not sprinkling manual calls to bus/pm_domain callbacks all over
I have send a patch a while ago for the PM core, that tried to
implement something similar like this, I wasn't accepted. I will
follow up on that asap.
Still, do you think we could go ahead with this patch? If/when we can
get an acceptance for a PM runtime helper function in the PM core, we
can easily convert to use it later on.
> the place, or maybe where we need to go is have a way for platforms that
> really are "runtime PM centric" to declare that even PM_SLEEP depends on
> PM_RUNTIME.
>
> I'm trying to thing of a good reason to not make PM_SLEEP depend on
> PM_RUNTIME for platforms like this.
This wont help. The PM core will still prevent the runtime_suspend
callback from being invoked during system suspend.
Kind regards
Ulf Hansson
>
> Kevin
>
^ permalink raw reply
* [PATCH] backlight: add PWM dependencies
From: Linus Walleij @ 2014-02-10 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210104032.GB20143@ulmo.nvidia.com>
On Mon, Feb 10, 2014 at 11:40 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> it seems like at least BACKLIGHT_LP8788 is missing a corresponding
> dependency as well.
>
> I have applied Sascha's patch to remove the obsolete HAVE_PWM symbol,
> and this will fix at least the build issues. However it will also cause
> the driver to fail at runtime because the pwm_*() functions won't work.
So it definately needs that API, not just stubs.
But isn't it proper for Kconfig to allow you to break things
like that by configuring out stuff and have stubs come in?
I'm a bit torn here.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210083836.44b519bf@amdc2363>
On 10/02/14 07:38, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
>
>> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
>> wrote:
>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>> <Sudeep.Holla@arm.com> wrote:
>>>
>>> [...]
>>>
>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>> userspace(list of frequencies and the boost parameters are
>>>>> exposed through sysfs)
>>>>
>>>> That will be a different problem -> as currently every single
>>>> frequency in the cpufreq list has ability to be marked as boost
>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>> the userspace :D
>>>>
>>>
>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>> gives the list of frequencies based on the state of the boost
>>> feature at anytime.
>>
>> The list of frequencies in
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>> does not change based in the state of the boost feature (enabled or
>> disabled). But the scaling_max_frequency and scaling_min_frequency are
>> updated based on the set of available + boost frequencies available.
>
> With boost intended behavior is as follow:
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]
>
> shows the non boost frequencies no matter if boost is enabled or not.
> Those are the "normal" frequencies.
>
> When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
> extra sysfs attribute shows up:
>
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
> in which are listed only the boost frequencies.
>
Correct, sorry I misunderstood this to dynamic change in
scaling_available_frequencies based on state of boot.
Regards,
Sudeep
^ permalink raw reply
* [PATCH 7/7] ARM: shmobile: lager dts: Enable Quad SPI transfers for the SPI FLASH
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-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>
---
This depends on spi-rspi updates
arch/arm/boot/dts/r8a7790-lager.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index adff2dc4012d..0b47ade38340 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -113,6 +113,8 @@
compatible = "spansion,s25fl512s";
reg = <0>;
spi-max-frequency = <30000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
m25p,fast-read;
partition at 0 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/7] ARM: shmobile: lager legacy: Enable Quad SPI transfers for the SPI FLASH
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-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>
---
This depends on spi-rspi updates
arch/arm/mach-shmobile/board-lager.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 9e52efa2a457..d7155375a322 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -298,12 +298,12 @@ static const struct rspi_plat_data qspi_pdata __initconst = {
static const struct spi_board_info spi_info[] __initconst = {
{
- .modalias = "m25p80",
- .platform_data = &spi_flash_data,
- .mode = SPI_MODE_0,
- .max_speed_hz = 30000000,
- .bus_num = 0,
- .chip_select = 0,
+ .modalias = "m25p80",
+ .platform_data = &spi_flash_data,
+ .mode = SPI_MODE_0 | SPI_TX_QUAD | SPI_RX_QUAD,
+ .max_speed_hz = 30000000,
+ .bus_num = 0,
+ .chip_select = 0,
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/7] ARM: shmobile: lager defconfig: Enable RSPI and MTD_M25P80
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
This enables support for the Spansion s25fl512s SPI FLASH on QSPI.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
arch/arm/configs/lager_defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
index 235772f7c81d..b17fc23ae676 100644
--- a/arch/arm/configs/lager_defconfig
+++ b/arch/arm/configs/lager_defconfig
@@ -51,6 +51,8 @@ CONFIG_IP_PNP_DHCP=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_MTD=y
+CONFIG_MTD_M25P80=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_SATA_RCAR=y
@@ -86,6 +88,8 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_I2C=y
CONFIG_I2C_GPIO=y
CONFIG_I2C_RCAR=y
+CONFIG_SPI=y
+CONFIG_SPI_RSPI=y
CONFIG_GPIO_SH_PFC=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_RCAR=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] ARM: shmobile: lager dts: Add QSPI nodes
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Add pinctrl and SPI devices for QSPI on Lager.
Add Spansion s25fl512s SPI FLASH and MTD partitions.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: devicetree at vger.kernel.org
Cc: linux-spi at vger.kernel.org
---
arch/arm/boot/dts/r8a7790-lager.dts | 36 +++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 1081c5e91ac4..adff2dc4012d 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -80,6 +80,11 @@
renesas,groups = "mmc1_data8", "mmc1_ctrl";
renesas,function = "mmc1";
};
+
+ qspi_pins: spi {
+ renesas,groups = "qspi_ctrl", "qspi_data4";
+ renesas,function = "qspi";
+ };
};
&mmcif1 {
@@ -95,3 +100,34 @@
&sata1 {
status = "okay";
};
+
+&spi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash: flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl512s";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ m25p,fast-read;
+
+ partition at 0 {
+ label = "loader";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+ partition at 40000 {
+ label = "user";
+ reg = <0x00040000 0x00400000>;
+ read-only;
+ };
+ partition at 440000 {
+ label = "flash";
+ reg = <0x00440000 0x03bc0000>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/7] ARM: shmobile: r8a7790 dtsi: Add QSPI node
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-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>
Cc: devicetree at vger.kernel.org
Cc: linux-spi at vger.kernel.org
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 54ab318af712..16bc116e0df4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -775,4 +775,16 @@
"rcan1", "rcan0", "qspi_mod", "i2c3", "i2c2", "i2c1", "i2c0";
};
};
+
+ spi: spi at e6b10000 {
+ compatible = "renesas,qspi-r8a7790", "renesas,qspi";
+ reg = <0 0xe6b10000 0 0x2c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7790_CLK_QSPI_MOD>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/7] ARM: shmobile: lager legacy: Add QSPI pinmux
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-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>
---
arch/arm/mach-shmobile/board-lager.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 317574864e7b..9e52efa2a457 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -606,6 +606,11 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
/* I2C2 */
PIN_MAP_MUX_GROUP_DEFAULT("i2c-rcar.2", "pfc-r8a7790",
"i2c2", "i2c2"),
+ /* QSPI */
+ PIN_MAP_MUX_GROUP_DEFAULT("qspi.0", "pfc-r8a7790",
+ "qspi_ctrl", "qspi"),
+ PIN_MAP_MUX_GROUP_DEFAULT("qspi.0", "pfc-r8a7790",
+ "qspi_data4", "qspi"),
/* SCIF0 (CN19: DEBUG SERIAL0) */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
"scif0_data", "scif0"),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/7] pinctrl: sh-pfc: r8a7790: Add QSPI pin groups
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392029254-15400-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
A QSPI function set consists of 3 groups:
- qspi_ctrl (2 control wires)
- qspi_data2 (2 data wires, for Single/Dual SPI)
- qspi_data4 (4 data wires, for Quad SPI)
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index c381ae63c508..bc9ced3ccd58 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -2389,6 +2389,29 @@ static const unsigned int msiof3_tx_pins[] = {
static const unsigned int msiof3_tx_mux[] = {
MSIOF3_TXD_MARK,
};
+/* - QSPI ------------------------------------------------------------------- */
+static const unsigned int qspi_ctrl_pins[] = {
+ /* SPCLK, SSL */
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 9),
+};
+static const unsigned int qspi_ctrl_mux[] = {
+ SPCLK_MARK, SSL_MARK,
+};
+static const unsigned int qspi_data2_pins[] = {
+ /* MOSI_IO0, MISO_IO1 */
+ RCAR_GP_PIN(1, 5), RCAR_GP_PIN(1, 6),
+};
+static const unsigned int qspi_data2_mux[] = {
+ MOSI_IO0_MARK, MISO_IO1_MARK,
+};
+static const unsigned int qspi_data4_pins[] = {
+ /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+ RCAR_GP_PIN(1, 5), RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 8),
+};
+static const unsigned int qspi_data4_mux[] = {
+ MOSI_IO0_MARK, MISO_IO1_MARK, IO2_MARK, IO3_MARK,
+};
/* - SCIF0 ------------------------------------------------------------------ */
static const unsigned int scif0_data_pins[] = {
/* RX, TX */
@@ -3671,6 +3694,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(msiof3_ss2),
SH_PFC_PIN_GROUP(msiof3_rx),
SH_PFC_PIN_GROUP(msiof3_tx),
+ SH_PFC_PIN_GROUP(qspi_ctrl),
+ SH_PFC_PIN_GROUP(qspi_data2),
+ SH_PFC_PIN_GROUP(qspi_data4),
SH_PFC_PIN_GROUP(scif0_data),
SH_PFC_PIN_GROUP(scif0_clk),
SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -3970,6 +3996,12 @@ static const char * const msiof3_groups[] = {
"msiof3_tx",
};
+static const char * const qspi_groups[] = {
+ "qspi_ctrl",
+ "qspi_data2",
+ "qspi_data4",
+};
+
static const char * const scif0_groups[] = {
"scif0_data",
"scif0_clk",
@@ -4212,6 +4244,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(msiof0),
SH_PFC_FUNCTION(msiof1),
SH_PFC_FUNCTION(msiof2),
+ SH_PFC_FUNCTION(qspi),
SH_PFC_FUNCTION(msiof3),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/7] ARM: shmobile: r8a7790/Lager QSPI SoC/board integration
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
The following patch series completes r8a7790 SoC and Lager board
integration for the Renesas Quad Serial Peripheral Interface. It brings
r8a7790/Lager to the same support level as r8a7791/Koelsch, allowing access
to the Spansion s25fl512s SPI FLASH for both legacy and multi-platform
kernels.
[1/7] pinctrl: sh-pfc: r8a7790: Add QSPI pin groups
[2/7] ARM: shmobile: lager legacy: Add QSPI pinmux
[3/7] ARM: shmobile: r8a7790 dtsi: Add QSPI node
[4/7] ARM: shmobile: lager dts: Add QSPI nodes
[5/7] ARM: shmobile: lager defconfig: Enable RSPI and MTD_M25P80
[6/7] ARM: shmobile: lager legacy: Enable Quad SPI transfers for the SPI
FLASH
[7/7] ARM: shmobile: lager dts: Enable Quad SPI transfers for the SPI
FLASH
Please do _not_ apply patches [6/7] and [7/7] yet, as these have a runtime
dependency on Quad SPI support in the RSPI/QSPI driver, which is queued up
in the linux-spi tree for v3.15.
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 v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9agcpbKYocaQUBr2-VCXcXAo3r3urFF=+G_+ib2jCZqvwg@mail.gmail.com>
On 08/02/14 06:47, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
>
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.
>
Ah ok, sorry just glanced the code and misunderstood it. It make sense to update
only max_frequency.
Regards,
Sudeep
^ 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