* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-11 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMj3TYLkvfGbq6BKqr+9i6mjArjRPuqeAN1-rGO2OhoSyw@mail.gmail.com>
On 10/11/16 19:03, Olof Johansson wrote:
> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 14:12, Rob Herring wrote:
>>>
>>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>>> operations.
>>>>>>
>>>>>> Required properties:
>>>>>>
>>>>>> -- compatible : should be "arm,scpi"
>>>>>> +- compatible : should be
>>>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>>> above
>>>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>>> v1.0
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>>> many?
>>>>>
>>>>
>>>> I understand your concern, but this legacy SCPI protocol was not
>>>> officially released. It was just WIP which vendors picked up from very
>>>> early releases. Since they are not numbered, it's hard to have specific
>>>> compatibles with different versions until v1.0. That's one of the reason
>>>> to retain platform specific compatible so that we can add any quirks
>>>> based on them if needed.
>>>>
>>>> I will probably add these information in the commit log so that it's
>>>> clear why we can't do version based compatible.
>>>
>>>
>>> This is exactly my point. By enumerate, I meant having platform
>>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>>> who knows what version they followed and they may all be different.
>>>
>>
>> OK, but IIUC Olof's concern wanted a generic one along with the platform
>> specific compatible which kind of makes sense as so far we have seen
>> some commonality between Amlogic and Rockchip.
>>
>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>> couple of things which we can handle with platform specific compatible
>> (in the following patch in the series). When another user(Rockchip ?)
>> make use of this legacy protocol, we can start using those platform
>> specific compatible for deviations only.
>>
>> Is that not acceptable ?
>
> If there's no shared legacy feature set, then it's probably less
> useful to have a shared less precise compatible value.
>
There is and will be some shared feature set for sure. At the least the
standard command set will be shared.
> What the main point I was trying to get across was that we shouldn't
> expand the generic binding with per-vendor compatible fields, instead
> we should have those as extensions on the side.
>
Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.
> I'm also a little apprehensive of using "legacy", it goes in the same
> bucket as "misc". At some point 1.0 will be legacy too, etc.
>
True and I agree, how about "arm,scpi-pre-1.0" instead ?
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Sahu @ 2016-11-11 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109164531.GA14630@htj.duckdns.org>
Hi Tejun,
On Wed, Nov 9, 2016 at 10:15 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
>> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
>> > *pdev)
>> > dev_warn(&pdev->dev, "%s: Error reading
>> > device info. Assume version1\n",
>> > __func__);
>> > version = XGENE_AHCI_V1;
>> > - } else if (info->valid & ACPI_VALID_CID) {
>> > - version = XGENE_AHCI_V2;
>
> Can you please explain this part a bit? Everything else looks good to
> me.
Here we should not assume XGENE_AHCI_V2 always in case of having valid
_CID in ACPI table.
I need to remove this assumption because V1_1 has also valid _CID for
backward compatibly with v1.
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* [PATCH] staging: vc04_services: fix setup_timer.cocci warnings
From: kbuild test robot @ 2016-11-11 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611111652.TBnh32bx%fengguang.wu@intel.com>
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1817:2-12: Use setup_timer function for function on line 1818.
Use setup_timer function instead of initializing timer with the function
and data fields
Generated by: scripts/coccinelle/api/setup_timer.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
Please take the patch only if it's a positive warning. Thanks!
vchiq_arm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1814,9 +1814,8 @@ vchiq_arm_init_state(VCHIQ_STATE_T *stat
arm_state->suspend_timer_timeout = SUSPEND_TIMER_TIMEOUT_MS;
arm_state->suspend_timer_running = 0;
- init_timer(&arm_state->suspend_timer);
- arm_state->suspend_timer.data = (unsigned long)(state);
- arm_state->suspend_timer.function = suspend_timer_callback;
+ setup_timer(&arm_state->suspend_timer, suspend_timer_callback,
+ (unsigned long)(state));
arm_state->first_connect = 0;
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-11 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110204852.GA31728@amd>
Hi,
On 10-11-16 21:48, Pavel Machek wrote:
> Hi!
>
>>>> It seems that we should get back to your initial approach. i.e. only
>>>> brightness changes caused by hardware should be reported.
>>>
>>> I don't think enabling poll() here is good idea. Some hardware won't
>>> be able to tell you that it changed the state. Returning maximum
>>> brightness trigger is going to use seems easier/better.
>>
>> The idea here is to allow userspace to poll() on the brightness
>> sysfs atrribute to detect changes autonomously done by the hardware,
>> such as e.g. happens on both Dell and Thinkpad laptops when pressing
>> the keyboard backlight cycle hotkey. Note that these keys do not
>> generate key-press events, the cycling through the brightness levels
>> (including off) is done entirely in firmware.
>
> Ok, so you can do that for keyboard backlight on thinkpad... I guess
> you handle that as a special trigger on the keyboard leds?
No, as said this is all done in firmware, as in this is all dealt
with by (presumably) the acpi-ec (acpi-embedded-controller) the kernel
does not do anything here, the key is "hardwired" to control the
keyboard backlight from the kernels pov.
> Can other
> triggers, such as heartbeat, be assigned to that "led"?
>
>> But we do get other ACPI events for this which we can use to let
>> userspace know this happens, which is something which user-
>> interfaces which allow control over the kbd backlight want to know.
>
> Yes, you can do that for keyboard backlight... but on thinkpads there
> are more leds, such as battery led. That can blink on battery low, and
> I don't think you can read the current status from hardware.
Well the battery LED does not show up under /sys/class/led so that
is not relevant for this situation, anyways ...
> Getting current state of led blinking with cpu trigger is also not
> quite a good idea.
I agree with you that it would be better if reading the brightness
sysfs attribute would always return the max brightness for LEDs
which are blinking or have a trigger set. But it seems that Jacek
disagrees, I will leave further discussion of this up to you and
Jacek.
> So IMO this should not be done in generic code. Instead,
> kbd-backlight trigger should have special attribute, and that one
> should be pollable.
Again there is no kbd-backlight trigger.
>> I understand that we will not always be able to do this, here is the
>> Documentation/ABI/testing/sysfs-class-led text I have in mind:
>>
>> The file supports poll() to detect changes, changes are only
>> signalled when this file is written or when the hardware /
>> firmware changes the brightness itself and the driver can detect
>> this. Changes done by kernel triggers / software blinking are
>> not signalled.
>>
>> Note the "and the driver can detect this" language, that has been there
>> since v1 of the poll() notification patch since I already expected not
>> all hardware to be able to signal this.
>
> Lets move it to separate attribute, for triggers that can do that,
> please.
As explained above this has nothing to do with triggers...
Regards,
Hans
^ permalink raw reply
* [PATCH v8 0/3] ARM, arm64: renesas: Enable UHS-I SDR-104
From: Simon Horman @ 2016-11-11 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110114659.GD1436@katana>
On Thu, Nov 10, 2016 at 12:47:00PM +0100, Wolfram Sang wrote:
> On Thu, Nov 03, 2016 at 04:07:22PM +0100, Simon Horman wrote:
> > Hi,
> >
> > this series enables SDHI UHS-I SDR-104 on:
> > * r8a7790/lager
> > * r8a7791/koelsch
> > * r8a7794/alt
> >
> > It is based on renesas-next-20161102-v4.9-rc1.
>
> For the whole series:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> For Lager:
>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Thanks, I have queued these up.
^ permalink raw reply
* [PATCH] pinctrl: sunxi: Free configs in pinctrl_map only if it is a config map
From: Maxime Ripard @ 2016-11-11 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111023510.14146-1-wens@csie.org>
On Fri, Nov 11, 2016 at 10:35:10AM +0800, Chen-Yu Tsai wrote:
> In the recently refactored sunxi pinctrl library, we are only allocating
> one set of pin configs for each pinmux setting node. When the pinctrl_map
> structure is freed, the pin configs should also be freed. However the
> code assumed the first map would contain the configs, which actually
> never happens, as the mux function map gets added first.
>
> The proper way to do this is to look through all the maps and free the
> first one whose type is actually PIN_MAP_TYPE_CONFIGS_GROUP.
>
> Also slightly expand the comment explaining this.
>
> Fixes: f233dbca6227 ("pinctrl: sunxi: Rework the pin config building code")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/e741e672/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN,UP} argument
From: Maxime Ripard @ 2016-11-11 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-2-wens@csie.org>
On Fri, Nov 11, 2016 at 10:44:53AM +0800, Chen-Yu Tsai wrote:
> According to pinconf-generic.h, the argument for
> PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled
> with a pull up/down resistor, zero if it is directly connected
> to VDD or ground.
>
> Since Allwinner hardware uses a weak pull resistor internally,
> the argument should be 1.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/bc2bfaf0/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
From: Maxime Ripard @ 2016-11-11 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-3-wens@csie.org>
On Fri, Nov 11, 2016 at 10:44:54AM +0800, Chen-Yu Tsai wrote:
> The sunxi pinctrl driver only caches whatever pinconf setting was last
> set on a given pingroup. This is not particularly helpful, nor is it
> correct.
>
> Fix this by actually reading the hardware registers and returning
> the correct results or error codes. Also filter out unsupported
> pinconf settings. Since this driver has a peculiar setup of 1 pin
> per group, we can support both pin and pingroup pinconf setting
> read back with the same code. The sunxi_pconf_reg helper and code
> structure is inspired by pinctrl-msm.
>
> With this done we can also claim to support generic pinconf, by
> setting .is_generic = true in pinconf_ops.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 84 +++++++++++++++++++++++++++++++++--
> 1 file changed, 81 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index e04edda8629d..3e9f7c675d36 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -438,15 +438,91 @@ static const struct pinctrl_ops sunxi_pctrl_ops = {
> .get_group_pins = sunxi_pctrl_get_group_pins,
> };
>
> +static int sunxi_pconf_reg(unsigned pin, enum pin_config_param param,
> + u32 *offset, u32 *shift, u32 *mask)
> +{
> + switch (param) {
> + case PIN_CONFIG_DRIVE_STRENGTH:
> + *offset = sunxi_dlevel_reg(pin);
> + *shift = sunxi_dlevel_offset(pin);
> + *mask = DLEVEL_PINS_MASK;
> + break;
> +
> + case PIN_CONFIG_BIAS_PULL_UP:
> + case PIN_CONFIG_BIAS_PULL_DOWN:
> + case PIN_CONFIG_BIAS_DISABLE:
> + *offset = sunxi_pull_reg(pin);
> + *shift = sunxi_pull_offset(pin);
> + *mask = PULL_PINS_MASK;
> + break;
> +
> + default:
> + return -ENOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static int sunxi_pconf_get(struct pinctrl_dev *pctldev, unsigned pin,
> + unsigned long *config)
> +{
> + struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
> + enum pin_config_param param = pinconf_to_config_param(*config);
> + u32 offset, shift, mask, val;
> + u16 arg;
> + int ret;
> +
> + pin -= pctl->desc->pin_base;
> +
> + ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask);
> + if (ret < 0)
> + return ret;
> +
> + val = (readl(pctl->membase + offset) >> shift) & mask;
> +
> + switch (pinconf_to_config_param(*config)) {
> + case PIN_CONFIG_DRIVE_STRENGTH:
> + arg = (val + 1) * 10;
> + break;
> +
> + case PIN_CONFIG_BIAS_PULL_UP:
> + if (val != SUN4I_PINCTRL_PULL_UP)
> + return -EINVAL;
> + arg = 1; /* hardware is weak pull-up */
> + break;
> +
> + case PIN_CONFIG_BIAS_PULL_DOWN:
> + if (val != SUN4I_PINCTRL_PULL_DOWN)
> + return -EINVAL;
> + arg = 1; /* hardware is weak pull-down */
> + break;
> +
> + case PIN_CONFIG_BIAS_DISABLE:
> + if (val != SUN4I_PINCTRL_NO_PULL)
> + return -EINVAL;
> + arg = 0;
> + break;
> +
> + default:
> + /* sunxi_pconf_reg should catch anything unsupported */
> + WARN_ON(1);
> + return -ENOTSUPP;
> + }
> +
> + *config = pinconf_to_config_packed(param, arg);
> +
> + return 0;
> +}
> +
> static int sunxi_pconf_group_get(struct pinctrl_dev *pctldev,
> unsigned group,
> unsigned long *config)
> {
> struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
> + struct sunxi_pinctrl_group *g = &pctl->groups[group];
>
> - *config = pctl->groups[group].config;
Do we still need this variable? Looking at the code, it doesn't look
that way, and we can remove the caching in the _group_set function and
the variable itslef in the sunxi_pincttrl_group structure.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/c66f592a/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
From: Maxime Ripard @ 2016-11-11 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-4-wens@csie.org>
On Fri, Nov 11, 2016 at 10:44:55AM +0800, Chen-Yu Tsai wrote:
> The sunxi_pconf_reg helper introduced in the last patch gives us the
> chance to rework sunxi_pconf_group_set to have it match the structure
> of sunxi_pconf_(group_)get and make it easier to understand.
>
> For each config to set, it:
>
> 1. checks if the parameter is supported.
> 2. checks if the argument is within limits.
> 3. converts argument to the register value.
> 4. writes to the register with spinlock held.
>
> As a result the function now blocks unsupported config parameters,
> instead of silently ignoring them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
But I think the config variable removal should be part of patch 2, as
discussed there.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/67b851bb/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
From: Chen-Yu Tsai @ 2016-11-11 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111083627.yooctcxqs4ow7sn3@lukather>
On Fri, Nov 11, 2016 at 4:36 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Nov 11, 2016 at 10:44:54AM +0800, Chen-Yu Tsai wrote:
>> The sunxi pinctrl driver only caches whatever pinconf setting was last
>> set on a given pingroup. This is not particularly helpful, nor is it
>> correct.
>>
>> Fix this by actually reading the hardware registers and returning
>> the correct results or error codes. Also filter out unsupported
>> pinconf settings. Since this driver has a peculiar setup of 1 pin
>> per group, we can support both pin and pingroup pinconf setting
>> read back with the same code. The sunxi_pconf_reg helper and code
>> structure is inspired by pinctrl-msm.
>>
>> With this done we can also claim to support generic pinconf, by
>> setting .is_generic = true in pinconf_ops.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 84 +++++++++++++++++++++++++++++++++--
>> 1 file changed, 81 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> index e04edda8629d..3e9f7c675d36 100644
>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> @@ -438,15 +438,91 @@ static const struct pinctrl_ops sunxi_pctrl_ops = {
>> .get_group_pins = sunxi_pctrl_get_group_pins,
>> };
>>
>> +static int sunxi_pconf_reg(unsigned pin, enum pin_config_param param,
>> + u32 *offset, u32 *shift, u32 *mask)
>> +{
>> + switch (param) {
>> + case PIN_CONFIG_DRIVE_STRENGTH:
>> + *offset = sunxi_dlevel_reg(pin);
>> + *shift = sunxi_dlevel_offset(pin);
>> + *mask = DLEVEL_PINS_MASK;
>> + break;
>> +
>> + case PIN_CONFIG_BIAS_PULL_UP:
>> + case PIN_CONFIG_BIAS_PULL_DOWN:
>> + case PIN_CONFIG_BIAS_DISABLE:
>> + *offset = sunxi_pull_reg(pin);
>> + *shift = sunxi_pull_offset(pin);
>> + *mask = PULL_PINS_MASK;
>> + break;
>> +
>> + default:
>> + return -ENOTSUPP;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_pconf_get(struct pinctrl_dev *pctldev, unsigned pin,
>> + unsigned long *config)
>> +{
>> + struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
>> + enum pin_config_param param = pinconf_to_config_param(*config);
>> + u32 offset, shift, mask, val;
>> + u16 arg;
>> + int ret;
>> +
>> + pin -= pctl->desc->pin_base;
>> +
>> + ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask);
>> + if (ret < 0)
>> + return ret;
>> +
>> + val = (readl(pctl->membase + offset) >> shift) & mask;
>> +
>> + switch (pinconf_to_config_param(*config)) {
>> + case PIN_CONFIG_DRIVE_STRENGTH:
>> + arg = (val + 1) * 10;
>> + break;
>> +
>> + case PIN_CONFIG_BIAS_PULL_UP:
>> + if (val != SUN4I_PINCTRL_PULL_UP)
>> + return -EINVAL;
>> + arg = 1; /* hardware is weak pull-up */
>> + break;
>> +
>> + case PIN_CONFIG_BIAS_PULL_DOWN:
>> + if (val != SUN4I_PINCTRL_PULL_DOWN)
>> + return -EINVAL;
>> + arg = 1; /* hardware is weak pull-down */
>> + break;
>> +
>> + case PIN_CONFIG_BIAS_DISABLE:
>> + if (val != SUN4I_PINCTRL_NO_PULL)
>> + return -EINVAL;
>> + arg = 0;
>> + break;
>> +
>> + default:
>> + /* sunxi_pconf_reg should catch anything unsupported */
>> + WARN_ON(1);
>> + return -ENOTSUPP;
>> + }
>> +
>> + *config = pinconf_to_config_packed(param, arg);
>> +
>> + return 0;
>> +}
>> +
>> static int sunxi_pconf_group_get(struct pinctrl_dev *pctldev,
>> unsigned group,
>> unsigned long *config)
>> {
>> struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
>> + struct sunxi_pinctrl_group *g = &pctl->groups[group];
>>
>> - *config = pctl->groups[group].config;
>
> Do we still need this variable? Looking at the code, it doesn't look
> that way, and we can remove the caching in the _group_set function and
> the variable itslef in the sunxi_pincttrl_group structure.
It's actually removed in the next patch. :)
ChenYu
^ permalink raw reply
* [PATCH v2 2/6] mfd: stm32-adc: Add support for stm32 ADC
From: Lee Jones @ 2016-11-11 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611110537.S7AVN9F6%fengguang.wu@intel.com>
On Fri, 11 Nov 2016, kbuild test robot wrote:
> Hi Fabrice,
>
> [auto build test ERROR on ljones-mfd/for-mfd-next]
> [also build test ERROR on v4.9-rc4 next-20161110]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Fabrice-Gasnier/Add-support-for-STM32-ADC/20161111-011922
> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
> config: s390-allmodconfig (attached as .config)
> compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=s390
>
> All errors (new ones prefixed by >>):
>
> drivers/mfd/stm32-adc-core: struct of_device_id is 200 bytes. The last of 1 is:
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x66 0x34 0x2d 0x61 0x64 0x63 0x2d 0x63 0x6f 0x72 0x65 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> >> FATAL: drivers/mfd/stm32-adc-core: struct of_device_id is not terminated with a NULL entry!
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Please fix this and re-submit.
--
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 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
From: Chen-Yu Tsai @ 2016-11-11 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111083852.yacy33g6pag6ucon@lukather>
On Fri, Nov 11, 2016 at 4:38 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Nov 11, 2016 at 10:44:55AM +0800, Chen-Yu Tsai wrote:
>> The sunxi_pconf_reg helper introduced in the last patch gives us the
>> chance to rework sunxi_pconf_group_set to have it match the structure
>> of sunxi_pconf_(group_)get and make it easier to understand.
>>
>> For each config to set, it:
>>
>> 1. checks if the parameter is supported.
>> 2. checks if the argument is within limits.
>> 3. converts argument to the register value.
>> 4. writes to the register with spinlock held.
>>
>> As a result the function now blocks unsupported config parameters,
>> instead of silently ignoring them.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> But I think the config variable removal should be part of patch 2, as
> discussed there.
OK. I think that makes sense. Re-reading my patches, I can't figure out,
which patch I meant for it to go in. :(
I'll send out a v3.
ChenYu
^ permalink raw reply
* [PATCH 5/5] drm/sun4i: Add support for the overscan profiles
From: Daniel Vetter @ 2016-11-11 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110145630.wvzlh6rxusrufv2r@lukather>
On Thu, Nov 10, 2016 at 03:56:30PM +0100, Maxime Ripard wrote:
> Hi Daniel,
>
> On Tue, Nov 08, 2016 at 09:59:27AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> > > Create overscan profiles reducing the displayed zone.
> > >
> > > For each TV standard (PAL and NTSC so far), we create 4 more reduced modes
> > > by steps of 5% that the user will be able to select.
> > >
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > tbh I think if we agree to do this (and that still seems an open question)
> > I think there should be a generic helper to add these overscan modes with
> > increased porches. Anything that only depends upon the sink (and
> > overscanning is something the sink does) should imo be put into a suitable
> > helper library for everyone to share.
> >
> > Or maybe even stash it into the probe helpers and call it for all TV
> > connectors. Definitely not a driver-private thing.
>
> Last time we discussed it, my recollection was that you didn't want to
> have generic code for it, but I'd be happy to implement it.
>
> I'll come up with something like that.
Well I can flip-flop around with the nonsense I'm sometimes emitting ;-)
Since you called me out, feel free to do whatever you want ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [Linaro-acpi] ACPI namespace details for ARM64
From: Lorenzo Pieralisi @ 2016-11-11 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a0829be4-6324-758b-2fe6-a274f715a3a9@linaro.org>
On Thu, Nov 10, 2016 at 04:18:54PM -0700, Al Stone wrote:
> On 11/09/2016 03:05 PM, Bjorn Helgaas wrote:
> > Hi all,
> >
> > We've been working through the details of getting ACPI to work on
> > arm64, and there have been lots of questions about what this means for
> > PCI. I've outlined this for several people individually, but I'm
> > going to send this separately, apart from a specific patch series, to
> > make sure we're all on the same page. Please correct my errors and
> > misunderstandings.
> >
> > Bjorn
> >
> >[snip....]
>
> A big +1 to all of this. This also looks like something that should
> be added to either PCI, ACPI or arm64 documentation (or even all three).
And to arm64 platforms FW :)
> What do you think?
I do not think there is anything ARM64 specific in Bjorn's description,
but I do think it is very useful to have it in documentation, these
bits of information are scattered around ACPI specs and PCI FW specs,
having a single source would help and would have prevented asking
Bjorn the same questions 100 times.
> Thank you for putting this together, Bjorn.
+1, Thank you very much for this nice summary Bjorn.
Lorenzo
^ permalink raw reply
* [PATCH v16 0/5] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2016-11-11 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY3mi3M0xqNao=DRYN6Np0LOBfS669iUa_hWo2w1MmM1sw@mail.gmail.com>
On Fri, 2016-11-11 at 11:15 +0530, Jassi Brar wrote:
> On Thu, Nov 10, 2016 at 4:45 PM, Horng-Shyang Liao <hs.liao@mediatek.com> wrote:
> > On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote:
> >> Hi,
> >>
> >> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> >> to help write registers with critical time limitation, such as
> >> updating display configuration during the vblank. It controls Global
> >> Command Engine (GCE) hardware to achieve this requirement.
> >>
> >> These patches have a build dependency on top of v4.9-rc1.
> >>
> >> Changes since v15:
> >> - separate "suspend and resume" patch from "save energy" patch
> >> - don't stop running tasks in cmdq_suspend()
> >> (i.e. leave no running tasks guarantee to clients)
> >>
> >> Best regards,
> >> HS Liao
> >>
> >> HS Liao (5):
> >> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> >> CMDQ: Mediatek CMDQ driver
> >> arm64: dts: mt8173: Add GCE node
> >> CMDQ: suspend and resume
> >> CMDQ: save energy
> >>
> >> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> >> drivers/mailbox/Kconfig | 10 +
> >> drivers/mailbox/Makefile | 2 +
> >> drivers/mailbox/mtk-cmdq-mailbox.c | 632 +++++++++++++++++++++
> >> drivers/soc/mediatek/Kconfig | 11 +
> >> drivers/soc/mediatek/Makefile | 1 +
> >> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++++++++++
> >> include/linux/mailbox/mtk-cmdq-mailbox.h | 67 +++
> >> include/linux/soc/mediatek/mtk-cmdq.h | 182 ++++++
> >> 10 files changed, 1268 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> >> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> >> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> >> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> >> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
> >>
> >
> >
> > Hi Jassi, Matthias,
> >
> > Sorry to disturb you.
> >
> No, you don't disturb, but the controller driver and protocol driver,
> introduced in the same patch, does :) So does the suspend/resume
> support (patch 4&5) added separately as a patch on top. Please
> reorganise the patchset.
>
> Thanks.
Hi Jassi,
Do you mean
1. split controller driver and protocol driver as two patches,
2. merge patch 4&5 into one patch, and
3. reorganize the patchset as "(1) binding doc (2) controller driver
(3) protocol driver (4) devicetree (5) energy patch" ?
Thanks,
HS
^ permalink raw reply
* [PATCH v3 0/3] pinctrl: sunxi: Support generic pinconf functions
From: Chen-Yu Tsai @ 2016-11-11 9:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This series fixes up generic pinconf support for the sunxi pinctrl driver
library. The driver was doing some bits wrong, like a) storing the pinconf
config value in its struct, and not actually reading the hardware to get
the current config, and b) not using the right arguments for the bias
parameters.
Patch 1 fixes the pin bias parameter arguments.
Patch 2 makes the driver read out pinconf settings from the hardware, and
returns the correct value for unsupported features and disable features.
With this in place it also declares itself as generic pinconf compatible,
which enables us to read the config through the debugfs pinconf interface.
Patch 3 makes the sunxi_pconf_group_set callback use the helper function
introduced in patch 1.
Changes since v2:
- Added Maxime's ack.
- Moved the removal of the cached config value from patch 3 to patch 2
at Maxime's request.
Changes since v1:
- Rebased onto the updated sunxi pinctrl driver with support for the
generic pinconf bindings
- Use separate value for what is written to the register in the pinconf
set function, as Maxime requested.
Regards
ChenYu
Chen-Yu Tsai (3):
pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN,UP} argument
pinctrl: sunxi: Add support for fetching pinconf settings from
hardware
pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 156 +++++++++++++++++++++++++---------
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 -
2 files changed, 118 insertions(+), 39 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v3 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN, UP} argument
From: Chen-Yu Tsai @ 2016-11-11 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-1-wens@csie.org>
According to pinconf-generic.h, the argument for
PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled
with a pull up/down resistor, zero if it is directly connected
to VDD or ground.
Since Allwinner hardware uses a weak pull resistor internally,
the argument should be 1.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index e199d95af8c0..e04edda8629d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -291,12 +291,16 @@ static unsigned long *sunxi_pctrl_build_pin_config(struct device_node *node,
if (sunxi_pctrl_has_bias_prop(node)) {
int pull = sunxi_pctrl_parse_bias_prop(node);
+ int arg = 0;
if (pull < 0) {
ret = pull;
goto err_free;
}
- pinconfig[idx++] = pinconf_to_config_packed(pull, 0);
+ if (pull != PIN_CONFIG_BIAS_DISABLE)
+ arg = 1; /* hardware uses weak pull resistors */
+
+ pinconfig[idx++] = pinconf_to_config_packed(pull, arg);
}
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
From: Chen-Yu Tsai @ 2016-11-11 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-1-wens@csie.org>
The sunxi pinctrl driver only caches whatever pinconf setting was last
set on a given pingroup. This is not particularly helpful, nor is it
correct.
Fix this by actually reading the hardware registers and returning
the correct results or error codes. Also filter out unsupported
pinconf settings. Since this driver has a peculiar setup of 1 pin
per group, we can support both pin and pingroup pinconf setting
read back with the same code. The sunxi_pconf_reg helper and code
structure is inspired by pinctrl-msm.
With this done we can also claim to support generic pinconf, by
setting .is_generic = true in pinconf_ops.
Also remove the cached config value. The behavior of this was never
correct, as it only cached 1 setting instead of all of them. Since
we can now read back settings directly from the hardware, it is no
longer required.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 86 +++++++++++++++++++++++++++++++++--
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 -
2 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index e04edda8629d..ed71bff39869 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -438,15 +438,91 @@ static const struct pinctrl_ops sunxi_pctrl_ops = {
.get_group_pins = sunxi_pctrl_get_group_pins,
};
+static int sunxi_pconf_reg(unsigned pin, enum pin_config_param param,
+ u32 *offset, u32 *shift, u32 *mask)
+{
+ switch (param) {
+ case PIN_CONFIG_DRIVE_STRENGTH:
+ *offset = sunxi_dlevel_reg(pin);
+ *shift = sunxi_dlevel_offset(pin);
+ *mask = DLEVEL_PINS_MASK;
+ break;
+
+ case PIN_CONFIG_BIAS_PULL_UP:
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ case PIN_CONFIG_BIAS_DISABLE:
+ *offset = sunxi_pull_reg(pin);
+ *shift = sunxi_pull_offset(pin);
+ *mask = PULL_PINS_MASK;
+ break;
+
+ default:
+ return -ENOTSUPP;
+ }
+
+ return 0;
+}
+
+static int sunxi_pconf_get(struct pinctrl_dev *pctldev, unsigned pin,
+ unsigned long *config)
+{
+ struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+ enum pin_config_param param = pinconf_to_config_param(*config);
+ u32 offset, shift, mask, val;
+ u16 arg;
+ int ret;
+
+ pin -= pctl->desc->pin_base;
+
+ ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask);
+ if (ret < 0)
+ return ret;
+
+ val = (readl(pctl->membase + offset) >> shift) & mask;
+
+ switch (pinconf_to_config_param(*config)) {
+ case PIN_CONFIG_DRIVE_STRENGTH:
+ arg = (val + 1) * 10;
+ break;
+
+ case PIN_CONFIG_BIAS_PULL_UP:
+ if (val != SUN4I_PINCTRL_PULL_UP)
+ return -EINVAL;
+ arg = 1; /* hardware is weak pull-up */
+ break;
+
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ if (val != SUN4I_PINCTRL_PULL_DOWN)
+ return -EINVAL;
+ arg = 1; /* hardware is weak pull-down */
+ break;
+
+ case PIN_CONFIG_BIAS_DISABLE:
+ if (val != SUN4I_PINCTRL_NO_PULL)
+ return -EINVAL;
+ arg = 0;
+ break;
+
+ default:
+ /* sunxi_pconf_reg should catch anything unsupported */
+ WARN_ON(1);
+ return -ENOTSUPP;
+ }
+
+ *config = pinconf_to_config_packed(param, arg);
+
+ return 0;
+}
+
static int sunxi_pconf_group_get(struct pinctrl_dev *pctldev,
unsigned group,
unsigned long *config)
{
struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+ struct sunxi_pinctrl_group *g = &pctl->groups[group];
- *config = pctl->groups[group].config;
-
- return 0;
+ /* We only support 1 pin per group. Chain it to the pin callback */
+ return sunxi_pconf_get(pctldev, g->pin, config);
}
static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev,
@@ -508,8 +584,6 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev,
default:
break;
}
- /* cache the config value */
- g->config = configs[i];
} /* for each config */
spin_unlock_irqrestore(&pctl->lock, flags);
@@ -518,6 +592,8 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev,
}
static const struct pinconf_ops sunxi_pconf_ops = {
+ .is_generic = true,
+ .pin_config_get = sunxi_pconf_get,
.pin_config_group_get = sunxi_pconf_group_get,
.pin_config_group_set = sunxi_pconf_group_set,
};
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 0afce1ab12d0..a7efb31d6523 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -109,7 +109,6 @@ struct sunxi_pinctrl_function {
struct sunxi_pinctrl_group {
const char *name;
- unsigned long config;
unsigned pin;
};
--
2.10.2
^ permalink raw reply related
* [PATCH v3 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
From: Chen-Yu Tsai @ 2016-11-11 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-1-wens@csie.org>
The sunxi_pconf_reg helper introduced in the last patch gives us the
chance to rework sunxi_pconf_group_set to have it match the structure
of sunxi_pconf_(group_)get and make it easier to understand.
For each config to set, it:
1. checks if the parameter is supported.
2. checks if the argument is within limits.
3. converts argument to the register value.
4. writes to the register with spinlock held.
As a result the function now blocks unsupported config parameters,
instead of silently ignoring them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 64 +++++++++++++++++------------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index ed71bff39869..fa11a3100346 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -532,23 +532,27 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev,
{
struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
struct sunxi_pinctrl_group *g = &pctl->groups[group];
- unsigned long flags;
unsigned pin = g->pin - pctl->desc->pin_base;
- u32 val, mask;
- u16 strength;
- u8 dlevel;
int i;
- spin_lock_irqsave(&pctl->lock, flags);
-
for (i = 0; i < num_configs; i++) {
- switch (pinconf_to_config_param(configs[i])) {
+ enum pin_config_param param;
+ unsigned long flags;
+ u32 offset, shift, mask, reg;
+ u16 arg, val;
+ int ret;
+
+ param = pinconf_to_config_param(configs[i]);
+ arg = pinconf_to_config_argument(configs[i]);
+
+ ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask);
+ if (ret < 0)
+ return ret;
+
+ switch (param) {
case PIN_CONFIG_DRIVE_STRENGTH:
- strength = pinconf_to_config_argument(configs[i]);
- if (strength > 40) {
- spin_unlock_irqrestore(&pctl->lock, flags);
+ if (arg < 10 || arg > 40)
return -EINVAL;
- }
/*
* We convert from mA to what the register expects:
* 0: 10mA
@@ -556,37 +560,33 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev,
* 2: 30mA
* 3: 40mA
*/
- dlevel = strength / 10 - 1;
- val = readl(pctl->membase + sunxi_dlevel_reg(pin));
- mask = DLEVEL_PINS_MASK << sunxi_dlevel_offset(pin);
- writel((val & ~mask)
- | dlevel << sunxi_dlevel_offset(pin),
- pctl->membase + sunxi_dlevel_reg(pin));
+ val = arg / 10 - 1;
break;
case PIN_CONFIG_BIAS_DISABLE:
- val = readl(pctl->membase + sunxi_pull_reg(pin));
- mask = PULL_PINS_MASK << sunxi_pull_offset(pin);
- writel((val & ~mask),
- pctl->membase + sunxi_pull_reg(pin));
+ val = 0;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- val = readl(pctl->membase + sunxi_pull_reg(pin));
- mask = PULL_PINS_MASK << sunxi_pull_offset(pin);
- writel((val & ~mask) | 1 << sunxi_pull_offset(pin),
- pctl->membase + sunxi_pull_reg(pin));
+ if (arg == 0)
+ return -EINVAL;
+ val = 1;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- val = readl(pctl->membase + sunxi_pull_reg(pin));
- mask = PULL_PINS_MASK << sunxi_pull_offset(pin);
- writel((val & ~mask) | 2 << sunxi_pull_offset(pin),
- pctl->membase + sunxi_pull_reg(pin));
+ if (arg == 0)
+ return -EINVAL;
+ val = 2;
break;
default:
- break;
+ /* sunxi_pconf_reg should catch anything unsupported */
+ WARN_ON(1);
+ return -ENOTSUPP;
}
- } /* for each config */
- spin_unlock_irqrestore(&pctl->lock, flags);
+ spin_lock_irqsave(&pctl->lock, flags);
+ reg = readl(pctl->membase + offset);
+ reg &= ~(mask << shift);
+ writel(reg | val << shift, pctl->membase + offset);
+ spin_unlock_irqrestore(&pctl->lock, flags);
+ } /* for each config */
return 0;
}
--
2.10.2
^ permalink raw reply related
* [PATCH] clk: sunxi-ng: sun8i-a23: Set CLK_SET_RATE_PARENT for audio module clocks
From: Chen-Yu Tsai @ 2016-11-11 10:05 UTC (permalink / raw)
To: linux-arm-kernel
The audio module clocks are supposed to be set according to the sample
rate of the audio stream. The audio PLL provides the clock signal for
thees module clocks, and only it is freely tunable.
Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
properly tune the clock rate.
Fixes: 5690879d93e8 ("clk: sunxi-ng: Add A23 CCU")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 2646d980087b..5c6d37bdf247 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -344,10 +344,10 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(spi1_clk, "spi1", mod0_default_parents, 0x0a4,
static const char * const i2s_parents[] = { "pll-audio-8x", "pll-audio-4x",
"pll-audio-2x", "pll-audio" };
static SUNXI_CCU_MUX_WITH_GATE(i2s0_clk, "i2s0", i2s_parents,
- 0x0b0, 16, 2, BIT(31), 0);
+ 0x0b0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_MUX_WITH_GATE(i2s1_clk, "i2s1", i2s_parents,
- 0x0b4, 16, 2, BIT(31), 0);
+ 0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
/* TODO: the parent for most of the USB clocks is not known */
static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M",
@@ -415,7 +415,7 @@ static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
0x13c, 16, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig", "pll-audio",
- 0x140, BIT(31), 0);
+ 0x140, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
0x144, BIT(31), 0);
--
2.10.2
^ permalink raw reply related
* [PATCH] clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks
From: Chen-Yu Tsai @ 2016-11-11 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111100558.14629-1-wens@csie.org>
The audio module clocks are supposed to be set according to the sample
rate of the audio stream. The audio PLL provides the clock signal for
thees module clocks, and only it is freely tunable.
Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
properly tune the clock rate.
Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 4d70590f05e3..21c427d86f28 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -394,16 +394,16 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(spi1_clk, "spi1", mod0_default_parents, 0x0a4,
static const char * const i2s_parents[] = { "pll-audio-8x", "pll-audio-4x",
"pll-audio-2x", "pll-audio" };
static SUNXI_CCU_MUX_WITH_GATE(i2s0_clk, "i2s0", i2s_parents,
- 0x0b0, 16, 2, BIT(31), 0);
+ 0x0b0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_MUX_WITH_GATE(i2s1_clk, "i2s1", i2s_parents,
- 0x0b4, 16, 2, BIT(31), 0);
+ 0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_MUX_WITH_GATE(i2s2_clk, "i2s2", i2s_parents,
- 0x0b8, 16, 2, BIT(31), 0);
+ 0x0b8, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_GATE(spdif_clk, "spdif", "pll-audio",
- 0x0c0, 0, 4, BIT(31), 0);
+ 0x0c0, 0, 4, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M",
0x0cc, BIT(8), 0);
@@ -466,7 +466,7 @@ static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
0x13c, 16, 3, BIT(31), 0);
static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig", "pll-audio",
- 0x140, BIT(31), 0);
+ 0x140, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
0x144, BIT(31), 0);
--
2.10.2
^ permalink raw reply related
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-11-11 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478806353.7430.137.camel@kernel.crashing.org>
Hi, Ben, Mark,
Thanks for your comments! These are helpful!
On 2016/11/11 3:32, Benjamin Herrenschmidt wrote:
> On Thu, 2016-11-10 at 11:22 +0000, Mark Rutland wrote:
>> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
>>> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>>
>> Just to check, do you hook that in your inb/outb/etc?
>
> Yes.
>
>> Generally, it would seem nicer if we could have higher-level
>> isa_{inb,outb,whatever} accessors that we could hook separately from
>> other IO.
>
> Maybe but generally speaking, we don't discriminate accessors per bus,
> ie, readl etc... work on all memory mapped busses, inb... works on all
> busses with an "IO space", at least that's been the idea. It probably
> all comes from the fact that PCI IO and ISA are the same space on
> x86 and most other platforms (not all).
>
>> We don't necessarily have to move all ISA drivers over to that if we had
>> a separate symbol for that interface.
>
> What I do on ppc today is that I have a chunk of virtual address space
> that is reserved for "IO space". The first 64k are "reserved" in that
> they route to "the primary" ISA bus (for legacy crap that uses hard
> coded addresses, though I use that for my LPC bus too). I "allocate"
> space for the PCI IO spaces higher in that space. Was I to support more
> LPC busses I could allocate them up there too.
>
I have similar idea as your PPC MMIO.
We notice the prototype of {in/out()} is something like that:
static inline u8 inb(unsigned long addr)
static inline void outb(u8 value, unsigned long addr)
The type of parameter 'addr' is unsigned long. For I/O space, it is big enough.
So, could you divide this 'addr' into several bit segments? The top 8 bits is
defined as bus index. For normal direct IO, the bus index is 0. For those bus
device which need indirectIO or some special I/O accessors, when these devices
are initializing, can request to allocate an unique ID to them, and register
their own accessors to the entry which is corresponding to the ID.
In this way, we can support multiple domains, I think.
But I am not sure whether it is feasible, for example, are there some
architectures/platforms had populated the top 8 bits? Do we need to request IO
region from ioport_resource for those devices? etc...
Thanks,
Zhichang
> The IO resource of a given device thus becomes the actual IO port plus
> the offset of the base of the segment it's in.
>
> For memory mapped IO, inb/outb will just add the virtual address of
> the base of all IO space to that. The hooking mechanism will pickup
> the stuff that isn't memory mapped.
>
> It's a bit messy but then IO space performance has never been a huge
> worry since IO cycles tend to be very slow to begin with.
>
> Note: We also have the ISA memory and ISA FW spaces that we don't have
> good accessors for. They somewhat exist (I think the fbdev layer uses
> some for vga) but it's messy.
>
> Cheers,
> Ben.
>
>
> .
>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-11 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10334260.ztLXZ2Oynd@wuerfel>
Hi, Arnd,
On 2016/11/11 0:07, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>>
>> Where should we get the range from? For LPC we know that it is going
>> Work on anything that is not used by PCI I/O space, and this is
>> why we use [0, PCIBIOS_MIN_IO]
>
> It should be allocated the same way we allocate PCI config space
> segments. This is currently done with the io_range list in
> drivers/pci/pci.c, which isn't perfect but could be extended
> if necessary. Based on what others commented here, I'd rather
> make the differences between ISA/LPC and PCI I/O ranges smaller
> than larger.
>
>>> Your current version has
>>>
>>> if (arm64_extio_ops->pfout) \
>>> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>>> addr, value, sizeof(type)); \
>>>
>>> Instead, just subtract the start of the range from the logical
>>> port number to transform it back into a bus-local port number:
>>
>> These accessors do not operate on IO tokens:
>>
>> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
>> addr is not going to be an I/O token; in fact patch 2/3 imposes that
>> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO
>> we have free physical addresses that the accessors can operate on.
>
> Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
> the logical I/O tokens, the purpose of that macro is really meant
> for allocating PCI I/O port numbers within the address space of
> one bus.
>
> Note that it's equally likely that whichever next platform needs
> non-mapped I/O access like this actually needs them for PCI I/O space,
> and that will use it on addresses registered to a PCI host bridge.
>
> If we separate the two steps:
>
> a) assign a range of logical I/O port numbers to a bus
> b) register a set of helpers for redirecting logical I/O
> port to a helper function
>
It seems that we need to add a new bus and the corresponding resource management
which can also cover current PCI pio mapping, is it right?
Thanks,
Zhichang
> then I think the code will get cleaner and more flexible.
> It should actually then be able to replace the powerpc
> specific implementation.
>
> Arnd
>
> .
>
^ permalink raw reply
* [linux-sunxi] [PATCH] clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks
From: Code Kipper @ 2016-11-11 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111100558.14629-2-wens@csie.org>
On 11 November 2016 at 11:05, Chen-Yu Tsai <wens@csie.org> wrote:
> The audio module clocks are supposed to be set according to the sample
> rate of the audio stream. The audio PLL provides the clock signal for
> thees module clocks, and only it is freely tunable.
nick! these
CK
>
> Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
> properly tune the clock rate.
>
> Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> index 4d70590f05e3..21c427d86f28 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> @@ -394,16 +394,16 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(spi1_clk, "spi1", mod0_default_parents, 0x0a4,
> static const char * const i2s_parents[] = { "pll-audio-8x", "pll-audio-4x",
> "pll-audio-2x", "pll-audio" };
> static SUNXI_CCU_MUX_WITH_GATE(i2s0_clk, "i2s0", i2s_parents,
> - 0x0b0, 16, 2, BIT(31), 0);
> + 0x0b0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
>
> static SUNXI_CCU_MUX_WITH_GATE(i2s1_clk, "i2s1", i2s_parents,
> - 0x0b4, 16, 2, BIT(31), 0);
> + 0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
>
> static SUNXI_CCU_MUX_WITH_GATE(i2s2_clk, "i2s2", i2s_parents,
> - 0x0b8, 16, 2, BIT(31), 0);
> + 0x0b8, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
>
> static SUNXI_CCU_M_WITH_GATE(spdif_clk, "spdif", "pll-audio",
> - 0x0c0, 0, 4, BIT(31), 0);
> + 0x0c0, 0, 4, BIT(31), CLK_SET_RATE_PARENT);
>
> static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M",
> 0x0cc, BIT(8), 0);
> @@ -466,7 +466,7 @@ static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
> 0x13c, 16, 3, BIT(31), 0);
>
> static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig", "pll-audio",
> - 0x140, BIT(31), 0);
> + 0x140, BIT(31), CLK_SET_RATE_PARENT);
> static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
> 0x144, BIT(31), 0);
>
> --
> 2.10.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PULL 0/3] KVM/ARM updates for v4.9-rc4
From: Paolo Bonzini @ 2016-11-11 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
On 04/11/2016 19:36, Marc Zyngier wrote:
> git://git.kernel.org:/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-v4.9-rc4
What is the extra colon after "org"? :)
Pulled now, and I will send it in time for rc5.
Thanks,
Paolo
^ 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