* [PATCH v9 2/8] power: add power sequence library
From: Peter Chen @ 2016-11-11 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0ioqMqoaJqK0CTXafWRKoohmZSiOWKRgVZ9DR3_8+-YDw@mail.gmail.com>
On Fri, Nov 11, 2016 at 02:05:01AM +0100, Rafael J. Wysocki wrote:
> On Tue, Nov 8, 2016 at 3:51 AM, Peter Chen <peter.chen@nxp.com> wrote:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> >
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices. The pwrseq
> > librares always need to allocate extra instance for compatible
> > string match.
> >
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover other controls in
> > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence is needed, else call of_pwrseq_on_list
> > /of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > For new power sequence library, it can add its compatible string
> > to pwrseq_of_match_table, then the pwrseq core will match it with
> > DT's, and choose this library at runtime.
>
> In the first place, please document this stuff better than you have so
> far. To a minimum, add kerneldoc comments to all new non-trivial new
> functions to document what they are for and how they are expected to
> be used (especially the ones exported to drivers).
>
Thanks for your comments.
I will add kerneldoc for main APIs.
> Also, is there any guidance available for people who may want to use it?
No doc now, only some guidance in this commit log.
> > +config PWRSEQ_GENERIC
> > + bool "Generic power sequence control"
> > + depends on OF
> > + select POWER_SEQUENCE
> > + help
> > + It is used for drivers which needs to do power sequence
> > + (eg, turn on clock, toggle reset gpio) before the related
> > + devices can be found by hardware. This generic one can be
> > + used for common power sequence control.
>
> I wouldn't set it up this way.
>
> There are two problems here.
>
> First, say a distro is going to ship a multiplatform generic kernel.
> How they are going to figure out whether or not to set the new symbol
> in that kernel?
>
> Second, how users are supposed to know whether or not they will need
> it even if they build the kernel by themselves?
>
> It would be better IMO to set things up to select the new symbol from
> places making use of the code depending on it.
>
Will change it like below:
#
# Power Sequence library
#
menuconfig POWER_SEQUENCE
bool "Power sequence control"
depends on OF
help
It is used for drivers which needs to do power sequence
(eg, turn on clock, toggle reset gpio) before the related
devices can be found by hardware.
if POWER_SEQUENCE
config PWRSEQ_GENERIC
bool "Generic power sequence control"
default y
help
This is the generic power sequence control library, and is
supposed to support common power sequence usage.
endif
And the current user usb core will select POWER_SEQUENCE.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH] pinctrl: sunxi: Free configs in pinctrl_map only if it is a config map
From: Chen-Yu Tsai @ 2016-11-11 2:35 UTC (permalink / raw)
To: linux-arm-kernel
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>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index ebe2c73d211e..e199d95af8c0 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -408,8 +408,21 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
struct pinctrl_map *map,
unsigned num_maps)
{
- /* All the maps have the same pin config, free only the first one */
- kfree(map[0].data.configs.configs);
+ int i;
+
+ /* pin config is never in the first map */
+ for (i = 1; i < num_maps; i++) {
+ if (map[i].type != PIN_MAP_TYPE_CONFIGS_GROUP)
+ continue;
+
+ /*
+ * All the maps share the same pin config,
+ * free only the first one we find.
+ */
+ kfree(map[i].data.configs.configs);
+ break;
+ }
+
kfree(map);
}
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/3] pinctrl: sunxi: Support generic pinconf functions
From: Chen-Yu Tsai @ 2016-11-11 2:44 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 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 v2 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN, UP} argument
From: Chen-Yu Tsai @ 2016-11-11 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-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>
---
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 v2 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
From: Chen-Yu Tsai @ 2016-11-11 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-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.
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;
-
- 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,
@@ -518,6 +594,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,
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
From: Chen-Yu Tsai @ 2016-11-11 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-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>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 66 +++++++++++++++++------------------
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 -
2 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 3e9f7c675d36..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,39 +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;
}
- /* cache the config value */
- g->config = configs[i];
- } /* 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;
}
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 v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-11 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110172720.GB17134@arm.com>
Will,
(+ Cc: Dennis)
On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > Add memblock_cap_memory_range() which will remove all the memblock regions
> > except the range specified in the arguments.
> >
> > This function, like memblock_mem_limit_remove_map(), will not remove
> > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > later as "device memory."
> > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > address the mem limit issue").
> >
> > This function is used, in a succeeding patch in the series of arm64 kdump
> > suuport, to limit the range of usable memory, System RAM, on crash dump
> > kernel.
> > (Please note that "mem=" parameter is of little use for this purpose.)
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: linux-mm at kvack.org
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/memblock.h | 1 +
> > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5b759c9..0e770af 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > phys_addr_t memblock_end_of_DRAM(void);
> > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > bool memblock_is_memory(phys_addr_t addr);
> > int memblock_is_map_memory(phys_addr_t addr);
> > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 7608bc3..eb53876 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > (phys_addr_t)ULLONG_MAX);
> > }
> >
> > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > +{
> > + int start_rgn, end_rgn;
> > + int i, ret;
> > +
> > + if (!size)
> > + return;
> > +
> > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > + &start_rgn, &end_rgn);
> > + if (ret)
> > + return;
> > +
> > + /* remove all the MAP regions */
> > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + for (i = start_rgn - 1; i >= 0; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + /* truncate the reserved regions */
> > + memblock_remove_range(&memblock.reserved, 0, base);
> > + memblock_remove_range(&memblock.reserved,
> > + base + size, (phys_addr_t)ULLONG_MAX);
> > +}
>
> This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> you not implement that in terms of your new, more general, function? e.g.
> by passing base == 0, and size == limit?
Obviously it's possible.
I actually talked to Dennis before about merging them,
but he was against my idea.
Thanks,
-Takahiro AKASHI
> Will
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Chen-Yu Tsai @ 2016-11-11 3:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+Bw4XVEJY6V4Hn+D_OmqEcp_nLLrVT0_i+jX_guCqzfA@mail.gmail.com>
On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Nov 6, 2016 at 7:56 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
>>> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
>>>> Quoting Peter Chen (2016-10-24 18:16:32)
>>>> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
>>>> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
>>>> > > > Hi,
>>>> > > >
>>>> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
>>>> > > > > The ULPI bus can be built as a module, and it will soon be
>>>> > > > > calling these functions when it supports probing devices from DT.
>>>> > > > > Export them so they can be used by the ULPI module.
>>>> > > > >
>>>> > > > > Acked-by: Rob Herring <robh@kernel.org>
>>>> > > > > Cc: <devicetree@vger.kernel.org>
>>>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
>>>> > > > > ---
>>>> > > > > drivers/of/device.c | 2 ++
>>>> > > > > 1 file changed, 2 insertions(+)
>>>> > > > >
>>>> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
>>>> > > > > index 8a22a253a830..6719ab35b62e 100644
>>>> > > > > --- a/drivers/of/device.c
>>>> > > > > +++ b/drivers/of/device.c
>>>> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
>>>> > > > >
>>>> > > > > return tsize;
>>>> > > > > }
>>>> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
>>>> > > > >
>>>> > > > > int of_device_request_module(struct device *dev)
>>>> > > > > {
>>>> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>>>> > > > > }
>>>> > > > > mutex_unlock(&of_mutex);
>>>> > > > > }
>>>> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>>>> > > >
>>>> > > > This is trailing the wrong function.
>>>> > > >
>>>> > >
>>>> > > Good catch. Must have been some bad rebase.
>>>> > >
>>>> > > Peter, can you fix it while applying or should I resend this patch?
>>>> > >
>>>> >
>>>> > But, this is device tree patch. I can only get chipidea part and other
>>>> > USB patches if Greg agrees.
>>>> >
>>>>
>>>> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
>>>> Rob acked them so they could go through usb with the other changes.
>>>
>>> I am just worried about possible merge error when linus pulls both OF
>>> and USB tree. Greg, is it ok the OF patches through USB tree with OF
>>> maintainer's ack?
>>
>> May I suggest putting the OF patches on an immutable branch so other
>> subsystems can pull them in without pulling in the USB patches? At
>> least I want to use them in the I2C subsystem, and in the sunxi-rsb
>> driver.
>
> Do you have patches using this already. If not, it is starting to get
> a bit late for v4.10.
>
> I can apply this, but then you'll just be pulling in other DT patches.
Not sure what you mean by "using" this...
I have patches which use this to add DT-based modalias entries for
module auto-loading to i2c and sunxi-rsb that I haven't sent.
As far as DT usage goes, we already need this for the axp20x mfd driver.
There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was
sent to fix module auto-loading by using the I2C client ID table:
mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=b7142a19321484bd7681aa547c1d50148c8e2825
But for the sunxi-rsb variant such a fix does not exist, as the bus
does not have a separate ID table. It uses DT exclusively.
Regards
ChenYu
^ permalink raw reply
* [PATCH v6 1/9] drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
From: Rongrong Zou @ 2016-11-11 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJTzmMNLXauNjrXE3-fZCus=Q4S8Hm=hyo_GoyC-QOs1A@mail.gmail.com>
Hi Sean,
Thanks for reviewing! All comments is helpful.
? 2016/11/11 1:35, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add DRM master driver for Hisilicon Hibmc SoC which used for
>> Out-of-band management. Blow is the general hardware connection,
>> both the Hibmc and the host CPU are on the same mother board.
>>
>> +----------+ +----------+
>> | | PCIe | Hibmc |
>> |host CPU( |<----->| display |
>> |arm64,x86)| |subsystem |
>> +----------+ +----------+
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/Kconfig | 1 +
>> drivers/gpu/drm/hisilicon/Makefile | 1 +
>> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 7 +
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 5 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 269 ++++++++++++++++++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 35 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.c | 85 +++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.h | 28 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 212 +++++++++++++++++
>> 9 files changed, 643 insertions(+)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.c
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.h
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
>>
>> diff --git a/drivers/gpu/drm/hisilicon/Kconfig b/drivers/gpu/drm/hisilicon/Kconfig
>> index 558c61b..2fd2724 100644
>> --- a/drivers/gpu/drm/hisilicon/Kconfig
>> +++ b/drivers/gpu/drm/hisilicon/Kconfig
>> @@ -2,4 +2,5 @@
>> # hisilicon drm device configuration.
>> # Please keep this list sorted alphabetically
>>
>> +source "drivers/gpu/drm/hisilicon/hibmc/Kconfig"
>> source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
>> diff --git a/drivers/gpu/drm/hisilicon/Makefile b/drivers/gpu/drm/hisilicon/Makefile
>> index e3f6d49..c8155bf 100644
>> --- a/drivers/gpu/drm/hisilicon/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/Makefile
>> @@ -2,4 +2,5 @@
>> # Makefile for hisilicon drm drivers.
>> # Please keep this list sorted alphabetically
>>
>> +obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc/
>> obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> new file mode 100644
>> index 0000000..a9af90d
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> @@ -0,0 +1,7 @@
>> +config DRM_HISI_HIBMC
>> + tristate "DRM Support for Hisilicon Hibmc"
>> + depends on DRM && PCI
>> +
>> + help
>> + Choose this option if you have a Hisilicon Hibmc soc chipset.
>> + If M is selected the module will be called hibmc-drm.
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> new file mode 100644
>> index 0000000..97cf4a0
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -0,0 +1,5 @@
>> +ccflags-y := -Iinclude/drm
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o
>> +
>> +obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>
> nit: Improper spacing here
seems a space was missed, thanks.
>
>> +#obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> new file mode 100644
>> index 0000000..4669d42
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -0,0 +1,269 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/console.h>
>> +
>> +#include "hibmc_drm_drv.h"
>> +#include "hibmc_drm_regs.h"
>> +#include "hibmc_drm_power.h"
>
> nit: Alphabetize headers
agreed, thanks.
>
>> +
>> +static const struct file_operations hibmc_fops = {
>> + .owner = THIS_MODULE,
>> + .open = drm_open,
>> + .release = drm_release,
>> + .unlocked_ioctl = drm_ioctl,
>> +#ifdef CONFIG_COMPAT
>
> drm_compat_ioctl is now initialized to NULL, so you can remove the #ifdef
>
understood, will remove it next version.
>> + .compat_ioctl = drm_compat_ioctl,
>> +#endif
>> + .poll = drm_poll,
>> + .read = drm_read,
>> + .llseek = no_llseek,
>> +};
>> +
>> +static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>> +{
>> + return 0;
>> +}
>> +
>> +static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> +{
>> +}
>> +
>> +static struct drm_driver hibmc_driver = {
>> + .fops = &hibmc_fops,
>> + .name = "hibmc",
>> + .date = "20160828",
>> + .desc = "hibmc drm driver",
>> + .major = 1,
>> + .minor = 0,
>> + .get_vblank_counter = drm_vblank_no_hw_counter,
>> + .enable_vblank = hibmc_enable_vblank,
>> + .disable_vblank = hibmc_disable_vblank,
>> +};
>> +
>> +static int hibmc_pm_suspend(struct device *dev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int hibmc_pm_resume(struct device *dev)
>> +{
>> + return 0;
>> +}
>> +
>> +static const struct dev_pm_ops hibmc_pm_ops = {
>> + SET_SYSTEM_SLEEP_PM_OPS(hibmc_pm_suspend,
>> + hibmc_pm_resume)
>> +};
>> +
>> +static int hibmc_hw_config(struct hibmc_drm_device *hidev)
>> +{
>> + unsigned int reg;
>> +
>> + /* On hardware reset, power mode 0 is default. */
>> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_MODE0);
>> +
>> + /* Enable display power gate & LOCALMEM power gate*/
>> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
>> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
>> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
>> + reg |= HIBMC_CURR_GATE_DISPLAY(ON);
>> + reg |= HIBMC_CURR_GATE_LOCALMEM(ON);
>> +
>> + hibmc_set_current_gate(hidev, reg);
>> +
>> + /* Reset the memory controller. If the memory controller
>> + * is not reset in chip,the system might hang when sw accesses
>> + * the memory.The memory should be resetted after
>> + * changing the MXCLK.
>> + */
>> + reg = readl(hidev->mmio + HIBMC_MISC_CTRL);
>> + reg &= ~HIBMC_MSCCTL_LOCALMEM_RESET_MASK;
>> + reg |= HIBMC_MSCCTL_LOCALMEM_RESET(RESET);
>> + writel(reg, hidev->mmio + HIBMC_MISC_CTRL);
>> +
>> + reg &= ~HIBMC_MSCCTL_LOCALMEM_RESET_MASK;
>> + reg |= HIBMC_MSCCTL_LOCALMEM_RESET(NORMAL);
>> +
>> + writel(reg, hidev->mmio + HIBMC_MISC_CTRL);
>> +
>> + /* We can add more initialization as needed. */
>> +
>> + return 0;
>
> Consider using void return type here to simplify error checking in the
> caller, especially since it looks like you aren't checking the return
> code, anyways :)
Yes, you are right. i did not check the return value, so void type
is better, thanks.
>
>> +}
>> +
>> +static int hibmc_hw_map(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct pci_dev *pdev = dev->pdev;
>> + resource_size_t addr, size, ioaddr, iosize;
>> +
>> + ioaddr = pci_resource_start(pdev, 1);
>> + iosize = MB(2);
>> +
>> + hidev->mmio = ioremap_nocache(ioaddr, iosize);
>
> Use devm_ioremap_nocache to avoid managing the resource directly
agreed, thanks
>
>> +
>
> nit: extra space
>
>> + if (!hidev->mmio) {
>> + DRM_ERROR("Cannot map mmio region\n");
>> + return -ENOMEM;
>> + }
>> +
>> + addr = pci_resource_start(pdev, 0);
>> + size = MB(32);
>
> Pull size and iosize out into #defines with descriptive names
agreed, thanks
>
>> +
>> + hidev->fb_map = ioremap(addr, size);
>
> Use devm_ioremap to avoid managing the resource directly.
agreed, thanks
>
>> + if (!hidev->fb_map) {
>> + DRM_ERROR("Cannot map framebuffer\n");
>> + return -ENOMEM;
>> + }
>> + hidev->fb_base = addr;
>> + hidev->fb_size = size;
>> +
>> + return 0;
>> +}
>> +
>> +static void hibmc_hw_fini(struct hibmc_drm_device *hidev)
>> +{
>> + if (hidev->mmio)
>> + iounmap(hidev->mmio);
>> + if (hidev->fb_map)
>> + iounmap(hidev->fb_map);
>> +}
>
> You don't need this function if you use the devm variants above
yes, it seems more simple :)
>
>> +
>> +static int hibmc_hw_init(struct hibmc_drm_device *hidev)
>> +{
>> + int ret;
>> +
>> + ret = hibmc_hw_map(hidev);
>> + if (ret)
>> + return ret;
>> +
>> + hibmc_hw_config(hidev);
>> +
>> + return 0;
>> +}
>> +
>> +static int hibmc_unload(struct drm_device *dev)
>> +{
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + hibmc_hw_fini(hidev);
>> + dev->dev_private = NULL;
>> + return 0;
>> +}
>> +
>> +static int hibmc_load(struct drm_device *dev, unsigned long flags)
>
> flags isn't used anywhere?
Initially, hibmc_load is assigned to ".load", so second parameter is reserved.
In fact it is not used.
>
>> +{
>> + struct hibmc_drm_device *hidev;
>> + int ret;
>> +
>> + hidev = devm_kzalloc(dev->dev, sizeof(*hidev), GFP_KERNEL);
>> + if (!hidev)
>
> Print error here?
applied, thanks.
>
>> + return -ENOMEM;
>> + dev->dev_private = hidev;
>> + hidev->dev = dev;
>> +
>> + ret = hibmc_hw_init(hidev);
>> + if (ret)
>> + goto err;
>> +
>> + return 0;
>> +
>> +err:
>> + hibmc_unload(dev);
>> + DRM_ERROR("failed to initialize drm driver.\n");
>
> Print the return value
ditto
>
>> + return ret;
>> +}
>> +
>> +static int hibmc_pci_probe(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct drm_device *dev;
>> + int ret;
>> +
>> + dev = drm_dev_alloc(&hibmc_driver, &pdev->dev);
>> + if (!dev)
>
> Print error here
ditto
>
>> + return -ENOMEM;
>> +
>> + dev->pdev = pdev;
>> + pci_set_drvdata(pdev, dev);
>> +
>> + ret = pci_enable_device(pdev);
>> + if (ret)
>
> and here, and in other failure paths
ditto
>
>> + goto err_free;
>> +
>> + ret = hibmc_load(dev, 0);
>> + if (ret)
>> + goto err_disable;
>> +
>> + ret = drm_dev_register(dev, 0);
>> + if (ret)
>> + goto err_unload;
>> +
>> + return 0;
>> +
>> +err_unload:
>> + hibmc_unload(dev);
>> +err_disable:
>> + pci_disable_device(pdev);
>> +err_free:
>> + drm_dev_unref(dev);
>> +
>> + return ret;
>> +}
>> +
>> +static void hibmc_pci_remove(struct pci_dev *pdev)
>> +{
>> + struct drm_device *dev = pci_get_drvdata(pdev);
>> +
>> + drm_dev_unregister(dev);
>> + hibmc_unload(dev);
>> + drm_dev_unref(dev);
>> +}
>> +
>> +static struct pci_device_id hibmc_pci_table[] = {
>> + {0x19e5, 0x1711, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
>> + {0,}
>> +};
>> +
>> +static struct pci_driver hibmc_pci_driver = {
>> + .name = "hibmc-drm",
>> + .id_table = hibmc_pci_table,
>> + .probe = hibmc_pci_probe,
>> + .remove = hibmc_pci_remove,
>> + .driver.pm = &hibmc_pm_ops,
>> +};
>> +
>> +static int __init hibmc_init(void)
>> +{
>> + return pci_register_driver(&hibmc_pci_driver);
>> +}
>> +
>> +static void __exit hibmc_exit(void)
>> +{
>> + return pci_unregister_driver(&hibmc_pci_driver);
>> +}
>> +
>> +module_init(hibmc_init);
>> +module_exit(hibmc_exit);
>> +
>> +MODULE_DEVICE_TABLE(pci, hibmc_pci_table);
>> +MODULE_AUTHOR("RongrongZou <zourongrong@huawei.com>");
>> +MODULE_DESCRIPTION("DRM Driver for Hisilicon Hibmc");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> new file mode 100644
>> index 0000000..0037341
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -0,0 +1,35 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#ifndef HIBMC_DRM_DRV_H
>> +#define HIBMC_DRM_DRV_H
>> +
>> +#include <drm/drmP.h>
>> +
>> +struct hibmc_drm_device {
>
> nit: Calling this hibmc_drm_priv would probably make things easier to
> read. When I read hibmc_drm_device, it makes me think that it's an
> extension of drm_device, which this isn't.
okay, will replace hibmc_drm_device with hibmc_drm_priv, thanks.
>
>
>> + /* hw */
>> + void __iomem *mmio;
>> + void __iomem *fb_map;
>> + unsigned long fb_base;
>> + unsigned long fb_size;
>> +
>> + /* drm */
>> + struct drm_device *dev;
>> +};
>> +
>> +#endif
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.c
>> new file mode 100644
>> index 0000000..1036542
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.c
>
> I don't think you need a new file for these functions. Just stash them
> in hibmc_drm_drv.c
okay, thanks.
>
>> @@ -0,0 +1,85 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include "hibmc_drm_drv.h"
>> +#include "hibmc_drm_regs.h"
>> +
>> +/*
>> + * It can operate in one of three modes: 0, 1 or Sleep.
>> + */
>> +void hibmc_set_power_mode(struct hibmc_drm_device *hidev,
>> + unsigned int power_mode)
>> +{
>> + unsigned int control_value = 0;
>> + void __iomem *mmio = hidev->mmio;
>> +
>> + if (power_mode > HIBMC_PW_MODE_CTL_MODE_SLEEP)
>> + return;
>> +
>> + control_value = readl(mmio + HIBMC_POWER_MODE_CTRL);
>> + control_value &= ~HIBMC_PW_MODE_CTL_MODE_MASK;
>> +
>> + control_value |= HIBMC_PW_MODE_CTL_MODE(power_mode) &
>> + HIBMC_PW_MODE_CTL_MODE_MASK;
>> +
>> + /* Set up other fields in Power Control Register */
>> + if (power_mode == HIBMC_PW_MODE_CTL_MODE_SLEEP) {
>> + control_value &= ~HIBMC_PW_MODE_CTL_OSC_INPUT_MASK;
>
> You do this in both branches of the conditional
sounds good to me, thanks :)
>
>> + control_value |= HIBMC_PW_MODE_CTL_OSC_INPUT(0) &
>> + HIBMC_PW_MODE_CTL_OSC_INPUT_MASK;
>> + } else {
>> + control_value &= ~HIBMC_PW_MODE_CTL_OSC_INPUT_MASK;
>> + control_value |= HIBMC_PW_MODE_CTL_OSC_INPUT(1) &
>> + HIBMC_PW_MODE_CTL_OSC_INPUT_MASK;
>> + }
>
> I think you could simplify this by adding a new local.
>
> unsigned int input = 1;
>
> if (power_mode == HIBMC_PW_MODE_CTL_MODE_SLEEP)
> input = 0;
>
> control_value = readl(mmio + HIBMC_POWER_MODE_CTRL);
> control_value &= ~(HIBMC_PW_MODE_CTL_MODE_MASK |
> HIBMC_PW_MODE_CTL_OSC_INPUT_MASK);
> control_value |= HIBMC_PW_MODE_CTL_MODE(power_mode) &
> HIBMC_PW_MODE_CTL_MODE_MASK;
> control_value |= HIBMC_PW_MODE_CTL_OSC_INPUT(input) &
> HIBMC_PW_MODE_CTL_OSC_INPUT_MASK;
agreed.
>
>
>> + /* Program new power mode. */
>> + writel(control_value, mmio + HIBMC_POWER_MODE_CTRL);
>> +}
>> +
>> +static unsigned int hibmc_get_power_mode(struct hibmc_drm_device *hidev)
>> +{
>> + void __iomem *mmio = hidev->mmio;
>> +
>> + return (readl(mmio + HIBMC_POWER_MODE_CTRL) &
>> + HIBMC_PW_MODE_CTL_MODE_MASK) >> HIBMC_PW_MODE_CTL_MODE_SHIFT;
>
> nit: You're doing a lot of work in the return statement here.
so i need to define an extra variable.
>
>> +}
>> +
>> +void hibmc_set_current_gate(struct hibmc_drm_device *hidev, unsigned int gate)
>> +{
>> + unsigned int gate_reg;
>> + unsigned int mode;
>> + void __iomem *mmio = hidev->mmio;
>> +
>> + /* Get current power mode. */
>
> nit: try to avoid comments that don't add value
okay, thanks.
>
>> + mode = hibmc_get_power_mode(hidev);
>> +
>> + switch (mode) {
>> + case HIBMC_PW_MODE_CTL_MODE_MODE0:
>> + gate_reg = HIBMC_MODE0_GATE;
>> + break;
>> +
>> + case HIBMC_PW_MODE_CTL_MODE_MODE1:
>> + gate_reg = HIBMC_MODE1_GATE;
>> + break;
>> +
>> + default:
>> + gate_reg = HIBMC_MODE0_GATE;
>> + break;
>> + }
>> + writel(gate, mmio + gate_reg);
>> +}
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.h
>> new file mode 100644
>> index 0000000..e20e1aa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_power.h
>> @@ -0,0 +1,28 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#ifndef HIBMC_DRM_POWER_H
>> +#define HIBMC_DRM_POWER_H
>> +
>> +#include "hibmc_drm_drv.h"
>> +
>> +void hibmc_set_power_mode(struct hibmc_drm_device *hidev,
>> + unsigned int power_mode);
>> +void hibmc_set_current_gate(struct hibmc_drm_device *hidev,
>> + unsigned int gate);
>> +#endif
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
>> new file mode 100644
>> index 0000000..9c804ca
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
>> @@ -0,0 +1,212 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#ifndef HIBMC_DRM_HW_H
>> +#define HIBMC_DRM_HW_H
>> +
>> +#define OFF 0
>> +#define ON 1
>> +#define DISABLE 0
>> +#define ENABLE 1
>
> These are not good names. I think you can probably hardcode the 0's
> and 1's in the code instead of these. However, if you want to use
> them, at least add a HIBMC_ prefix
I like hardcode here, thanks.
>
>> +
>> +/* register definition */
>> +#define HIBMC_MISC_CTRL 0x4
>> +
>> +#define HIBMC_MSCCTL_LOCALMEM_RESET(x) ((x) << 6)
>> +#define HIBMC_MSCCTL_LOCALMEM_RESET_MASK 0x40
>> +
>> +#define RESET 0
>> +#define NORMAL 1
>
> Same naming nit here. Add a prefix
ditto.
>
>> +
>> +#define HIBMC_CURRENT_GATE 0x000040
>> +#define HIBMC_CURR_GATE_DISPLAY(x) ((x) << 2)
>> +#define HIBMC_CURR_GATE_DISPLAY_MASK 0x4
>> +
>> +#define HIBMC_CURR_GATE_LOCALMEM(x) ((x) << 1)
>> +#define HIBMC_CURR_GATE_LOCALMEM_MASK 0x2
>> +
>> +#define HIBMC_MODE0_GATE 0x000044
>> +#define HIBMC_MODE1_GATE 0x000048
>> +#define HIBMC_POWER_MODE_CTRL 0x00004C
>> +
>> +#define HIBMC_PW_MODE_CTL_OSC_INPUT(x) ((x) << 3)
>> +#define HIBMC_PW_MODE_CTL_OSC_INPUT_MASK 0x8
>> +
>> +#define HIBMC_PW_MODE_CTL_MODE(x) ((x) << 0)
>> +#define HIBMC_PW_MODE_CTL_MODE_MASK 0x03
>> +#define HIBMC_PW_MODE_CTL_MODE_SHIFT 0
>> +
>> +#define HIBMC_PW_MODE_CTL_MODE_MODE0 0
>> +#define HIBMC_PW_MODE_CTL_MODE_MODE1 1
>> +#define HIBMC_PW_MODE_CTL_MODE_SLEEP 2
>> +
>> +#define HIBMC_PANEL_PLL_CTRL 0x00005C
>> +#define HIBMC_CRT_PLL_CTRL 0x000060
>> +
>> +#define HIBMC_PLL_CTRL_BYPASS(x) ((x) << 18)
>> +#define HIBMC_PLL_CTRL_BYPASS_MASK 0x40000
>> +
>> +#define HIBMC_PLL_CTRL_POWER(x) ((x) << 17)
>> +#define HIBMC_PLL_CTRL_POWER_MASK 0x20000
>> +
>> +#define HIBMC_PLL_CTRL_INPUT(x) ((x) << 16)
>> +#define HIBMC_PLL_CTRL_INPUT_MASK 0x10000
>> +
>> +#define OSC 0
>
> Naming
ditto.
>
>> +#define TESTCLK 1
>
> This doesn't seem to be used?
will remove it in next version.
>
>> +
>> +#define HIBMC_PLL_CTRL_POD(x) ((x) << 14)
>> +#define HIBMC_PLL_CTRL_POD_MASK 0xC000
>> +
>> +#define HIBMC_PLL_CTRL_OD(x) ((x) << 12)
>> +#define HIBMC_PLL_CTRL_OD_MASK 0x3000
>> +
>> +#define HIBMC_PLL_CTRL_N(x) ((x) << 8)
>> +#define HIBMC_PLL_CTRL_N_MASK 0xF00
>> +
>> +#define HIBMC_PLL_CTRL_M(x) ((x) << 0)
>> +#define HIBMC_PLL_CTRL_M_MASK 0xFF
>> +
>> +#define HIBMC_CRT_DISP_CTL 0x80200
>> +
>> +#define HIBMC_CRT_DISP_CTL_CRTSELECT(x) ((x) << 25)
>> +#define HIBMC_CRT_DISP_CTL_CRTSELECT_MASK 0x2000000
>> +
>> +#define CRTSELECT_VGA 0
>> +#define CRTSELECT_CRT 1
>> +
>> +#define HIBMC_CRT_DISP_CTL_CLOCK_PHASE(x) ((x) << 14)
>> +#define HIBMC_CRT_DISP_CTL_CLOCK_PHASE_MASK 0x4000
>> +
>> +#define PHASE_ACTIVE_HIGH 0
>> +#define PHASE_ACTIVE_LOW 1
>> +
>> +#define HIBMC_CRT_DISP_CTL_VSYNC_PHASE(x) ((x) << 13)
>> +#define HIBMC_CRT_DISP_CTL_VSYNC_PHASE_MASK 0x2000
>> +
>> +#define HIBMC_CRT_DISP_CTL_HSYNC_PHASE(x) ((x) << 12)
>> +#define HIBMC_CRT_DISP_CTL_HSYNC_PHASE_MASK 0x1000
>> +
>> +#define HIBMC_CRT_DISP_CTL_TIMING(x) ((x) << 8)
>> +#define HIBMC_CRT_DISP_CTL_TIMING_MASK 0x100
>> +
>> +#define HIBMC_CRT_DISP_CTL_PLANE(x) ((x) << 2)
>> +#define HIBMC_CRT_DISP_CTL_PLANE_MASK 4
>> +
>> +#define HIBMC_CRT_DISP_CTL_FORMAT(x) ((x) << 0)
>> +#define HIBMC_CRT_DISP_CTL_FORMAT_MASK 0x03
>> +
>> +#define HIBMC_CRT_FB_ADDRESS 0x080204
>> +
>> +#define HIBMC_CRT_FB_WIDTH 0x080208
>> +#define HIBMC_CRT_FB_WIDTH_WIDTH(x) ((x) << 16)
>> +#define HIBMC_CRT_FB_WIDTH_WIDTH_MASK 0x3FFF0000
>> +#define HIBMC_CRT_FB_WIDTH_OFFS(x) ((x) << 0)
>> +#define HIBMC_CRT_FB_WIDTH_OFFS_MASK 0x3FFF
>> +
>> +#define HIBMC_CRT_HORZ_TOTAL 0x08020C
>> +#define HIBMC_CRT_HORZ_TOTAL_TOTAL(x) ((x) << 16)
>> +#define HIBMC_CRT_HORZ_TOTAL_TOTAL_MASK 0xFFF0000
>> +
>> +#define HIBMC_CRT_HORZ_TOTAL_DISPLAY_END(x) ((x) << 0)
>> +#define HIBMC_CRT_HORZ_TOTAL_DISPLAY_END_MASK 0xFFF
>> +
>> +#define HIBMC_CRT_HORZ_SYNC 0x080210
>> +#define HIBMC_CRT_HORZ_SYNC_WIDTH(x) ((x) << 16)
>> +#define HIBMC_CRT_HORZ_SYNC_WIDTH_MASK 0xFF0000
>> +
>> +#define HIBMC_CRT_HORZ_SYNC_START(x) ((x) << 0)
>> +#define HIBMC_CRT_HORZ_SYNC_START_MASK 0xFFF
>> +
>> +#define HIBMC_CRT_VERT_TOTAL 0x080214
>> +#define HIBMC_CRT_VERT_TOTAL_TOTAL(x) ((x) << 16)
>> +#define HIBMC_CRT_VERT_TOTAL_TOTAL_MASK 0x7FFF0000
>> +
>> +#define HIBMC_CRT_VERT_TOTAL_DISPLAY_END(x) ((x) << 0)
>> +#define HIBMC_CRT_VERT_TOTAL_DISPLAY_END_MASK 0x7FF
>> +
>> +#define HIBMC_CRT_VERT_SYNC 0x080218
>> +#define HIBMC_CRT_VERT_SYNC_HEIGHT(x) ((x) << 16)
>> +#define HIBMC_CRT_VERT_SYNC_HEIGHT_MASK 0x3F0000
>> +
>> +#define HIBMC_CRT_VERT_SYNC_START(x) ((x) << 0)
>> +#define HIBMC_CRT_VERT_SYNC_START_MASK 0x7FF
>> +
>> +/* Auto Centering */
>> +#define HIBMC_CRT_AUTO_CENTERING_TL 0x080280
>> +#define HIBMC_CRT_AUTO_CENTERING_TL_TOP(x) ((x) << 16)
>> +#define HIBMC_CRT_AUTO_CENTERING_TL_TOP_MSK 0x7FF0000
>> +
>> +#define HIBMC_CRT_AUTO_CENTERING_TL_LEFT(x) ((x) << 0)
>> +#define HIBMC_CRT_AUTO_CENTERING_TL_LEFT_MSK 0x7FF
>> +
>> +#define HIBMC_CRT_AUTO_CENTERING_BR 0x080284
>> +#define HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM(x) ((x) << 16)
>> +#define HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM_MASK 0x7FF0000
>> +
>> +#define HIBMC_CRT_AUTO_CENTERING_BR_RIGHT(x) ((x) << 0)
>> +#define HIBMC_CRT_AUTO_CENTERING_BR_RIGHT_MASK 0x7FF
>> +
>> +/* register to control panel output */
>> +#define DISPLAY_CONTROL_HISILE 0x80288
>> +
>> +#define HIBMC_RAW_INTERRUPT 0x80290
>> +#define HIBMC_RAW_INTERRUPT_VBLANK(x) ((x) << 2)
>> +#define HIBMC_RAW_INTERRUPT_VBLANK_MASK 0x4
>> +
>> +#define HIBMC_RAW_INTERRUPT_EN 0x80298
>> +#define HIBMC_RAW_INTERRUPT_EN_VBLANK(x) ((x) << 2)
>> +#define HIBMC_RAW_INTERRUPT_EN_VBLANK_MASK 0x4
>> +
>> +/* register and values for PLL control */
>> +#define CRT_PLL1_HS 0x802a8
>> +#define CRT_PLL1_HS_25MHZ 0x23d40f02
>> +#define CRT_PLL1_HS_40MHZ 0x23940801
>> +#define CRT_PLL1_HS_65MHZ 0x23940d01
>> +#define CRT_PLL1_HS_78MHZ 0x23540F82
>> +#define CRT_PLL1_HS_74MHZ 0x23941dc2
>> +#define CRT_PLL1_HS_80MHZ 0x23941001
>> +#define CRT_PLL1_HS_80MHZ_1152 0x23540fc2
>> +#define CRT_PLL1_HS_108MHZ 0x23b41b01
>> +#define CRT_PLL1_HS_162MHZ 0x23480681
>> +#define CRT_PLL1_HS_148MHZ 0x23541dc2
>> +#define CRT_PLL1_HS_193MHZ 0x234807c1
>> +
>> +#define CRT_PLL2_HS 0x802ac
>> +#define CRT_PLL2_HS_25MHZ 0x206B851E
>> +#define CRT_PLL2_HS_40MHZ 0x30000000
>> +#define CRT_PLL2_HS_65MHZ 0x40000000
>> +#define CRT_PLL2_HS_78MHZ 0x50E147AE
>> +#define CRT_PLL2_HS_74MHZ 0x602B6AE7
>> +#define CRT_PLL2_HS_80MHZ 0x70000000
>> +#define CRT_PLL2_HS_108MHZ 0x80000000
>> +#define CRT_PLL2_HS_162MHZ 0xA0000000
>> +#define CRT_PLL2_HS_148MHZ 0xB0CCCCCD
>> +#define CRT_PLL2_HS_193MHZ 0xC0872B02
>> +
>> +/* Global macros */
>> +#define RGB(r, g, b) \
>
> Not used anywhere?
will remove it in next version.
>
>> +( \
>> + (unsigned long)(((r) << 16) | ((g) << 8) | (b)) \
>> +)
>> +
>> +#define PADDING(align, data) (((data) + (align) - 1) & (~((align) - 1)))
>> +
>
> This is only used in hibmc_drm_de.c, move it in there. It might also
> be nice to make it a type-checked function while you're at it.
agreed, thanks.
>
>
>> +#define MB(x) ((x) << 20)
>> +
>
> This is only used in 2 places, I think you can just hardcode the value
> in their respective #defines
agreed, thanks.
Regards,
Rongrong.
>
>> +#endif
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
^ permalink raw reply
* [PATCH] regulator: axp20x: Fix axp809 ldo_io registration error on cold boot
From: Chen-Yu Tsai @ 2016-11-11 3:12 UTC (permalink / raw)
To: linux-arm-kernel
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot
the selector comes up at 0x1f, which maps to 3.8V. This was previously
corrected by Allwinner's U-boot, which set all regulators on the PMICs
to some pre-configured voltage. With recent progress in U-boot SPL
support, this is no longer the case. In any case we should handle
this quirk in the kernel driver as well.
This invalid setting causes _regulator_get_voltage() to fail with -EINVAL
which causes regulator registration to fail when constrains are used:
[ 1.054181] vcc-pg: failed to get the current voltage(-22)
[ 1.059670] axp20x-regulator axp20x-regulator.0: Failed to register ldo_io0
[ 1.069749] axp20x-regulator: probe of axp20x-regulator.0 failed with error -22
This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.
The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.
This is essentially the same as the commit f40d4896bf32 ("regulator:
axp20x: Fix axp22x ldo_io registration error on cold boot") for AXP22x
PMICs.
Fixes: a51f9f4622a3 ("regulator: axp20x: support AXP809 variant")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/regulator/axp20x-regulator.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 54382ef902c6..e6a512ebeae2 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -337,10 +337,18 @@ static const struct regulator_desc axp809_regulators[] = {
AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100,
AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
- AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ /*
+ * Note the datasheet only guarantees reliable operation up to
+ * 3.3V, this needs to be enforced via dts provided constraints
+ */
+ AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3800, 100,
AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
- AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ /*
+ * Note the datasheet only guarantees reliable operation up to
+ * 3.3V, this needs to be enforced via dts provided constraints
+ */
+ AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3800, 100,
AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800),
--
2.10.2
^ permalink raw reply related
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: Dennis Chen @ 2016-11-11 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111025049.GG381@linaro.org>
On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> Will,
> (+ Cc: Dennis)
>
> On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > Add memblock_cap_memory_range() which will remove all the memblock regions
> > > except the range specified in the arguments.
> > >
> > > This function, like memblock_mem_limit_remove_map(), will not remove
> > > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > > later as "device memory."
> > > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > > address the mem limit issue").
> > >
> > > This function is used, in a succeeding patch in the series of arm64 kdump
> > > suuport, to limit the range of usable memory, System RAM, on crash dump
> > > kernel.
> > > (Please note that "mem=" parameter is of little use for this purpose.)
> > >
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Cc: linux-mm at kvack.org
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > ---
> > > include/linux/memblock.h | 1 +
> > > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > > 2 files changed, 29 insertions(+)
> > >
> > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > index 5b759c9..0e770af 100644
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > > phys_addr_t memblock_end_of_DRAM(void);
> > > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > > bool memblock_is_memory(phys_addr_t addr);
> > > int memblock_is_map_memory(phys_addr_t addr);
> > > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > index 7608bc3..eb53876 100644
> > > --- a/mm/memblock.c
> > > +++ b/mm/memblock.c
> > > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > > (phys_addr_t)ULLONG_MAX);
> > > }
> > >
> > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > +{
> > > + int start_rgn, end_rgn;
> > > + int i, ret;
> > > +
> > > + if (!size)
> > > + return;
> > > +
> > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > + &start_rgn, &end_rgn);
> > > + if (ret)
> > > + return;
> > > +
> > > + /* remove all the MAP regions */
> > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > + memblock_remove_region(&memblock.memory, i);
> > > +
> > > + for (i = start_rgn - 1; i >= 0; i--)
> > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > + memblock_remove_region(&memblock.memory, i);
> > > +
> > > + /* truncate the reserved regions */
> > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > + memblock_remove_range(&memblock.reserved,
> > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > +}
> >
> > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > you not implement that in terms of your new, more general, function? e.g.
> > by passing base == 0, and size == limit?
>
> Obviously it's possible.
> I actually talked to Dennis before about merging them,
> but he was against my idea.
>
Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
So feel free to do that as Will'll do
>
> Thanks,
> -Takahiro AKASHI
>
> > Will
^ permalink raw reply
* [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Masahiro Yamada @ 2016-11-11 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110133559.GA10191@kroah.com>
2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
>>
>> sdhci_alloc_host() returns an error pointer when it fails.
>> but mmc_alloc_host() cannot.
>>
>> This series allow to propagate a proper error code
>> when host-allocation fails.
>
> Why? What can we really do about the error except give up? Why does
> having a explicit error value make any difference to the caller, they
> can't do anything different, right?
The error code is shown in the console, like
probe of 5a000000.sdhc failed with error -12
The proper error code will give a clue
why the driver failed to probe.
> I suggest just leaving it as-is, it's simple, and you don't have to mess
> with PTR_ERR() anywhere.
Why?
Most of driver just give up probing for any error,
but we still do ERR_PTR()/PTR_ERR() here and there.
I think this patch is the same pattern.
If a function returns NULL on failure, we need to think about
"what is the most common failure case".
Currently, MMC drivers assume -ENOMEM is the best
fit for mmc_alloc_host(), but the assumption is fragile.
Already, mmc_alloc_host() calls a function
that returns not only -ENOMEM, but also -ENOSPC.
In the future, some other failure cases might be
added to mmc_alloc_host().
Once we decide the API returns an error pointer,
drivers just propagate the return value from the API.
This is much more stable implementation.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH -next] cpufreq: brcmstb-avs-cpufreq: make symbol brcm_avs_cpufreq_attr static
From: Viresh Kumar @ 2016-11-11 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791145-21137-1-git-send-email-weiyj.lk@gmail.com>
On 10-11-16, 15:19, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/cpufreq/brcmstb-avs-cpufreq.c:982:18: warning:
> symbol 'brcm_avs_cpufreq_attr' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> index b761d54..4fda623 100644
> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> @@ -979,7 +979,7 @@ cpufreq_freq_attr_ro(brcm_avs_pmap);
> cpufreq_freq_attr_ro(brcm_avs_voltage);
> cpufreq_freq_attr_ro(brcm_avs_frequency);
>
> -struct freq_attr *brcm_avs_cpufreq_attr[] = {
> +static struct freq_attr *brcm_avs_cpufreq_attr[] = {
> &cpufreq_freq_attr_scaling_available_freqs,
> &brcm_avs_pstate,
> &brcm_avs_mode,
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Jisheng Zhang @ 2016-11-11 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15b06a12-ed69-03a7-ccc7-0c133ce1ac1e@marvell.com>
Hi Rob, Ziji,
On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote:
> Hi Rob,
>
> On 2016/11/10 2:24, Rob Herring wrote:
> > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
> >> From: Ziji Hu <huziji@marvell.com>
> >>
> >> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> >> Add Xenon-specific properties.
> >> Also add properties for Xenon PHY setting.
> >>
> >> Signed-off-by: Hu Ziji <huziji@marvell.com>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
> >> MAINTAINERS | 1 +-
> >> 2 files changed, 162 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >> new file mode 100644
> >> index 000000000000..0d2d139494d3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >> @@ -0,0 +1,161 @@
> >> +Marvell's Xenon SDHCI Controller device tree bindings
> >> +This file documents differences between the core mmc properties
> >> +described by mmc.txt and the properties used by the Xenon implementation.
> >> +
> >> +A single Xenon IP can support multiple slots.
> >> +Each slot acts as an independent SDHC. It owns independent resources, such
> >> +as register sets clock and PHY.
> >> +Each slot should have an independent device tree node.
> >> +
> >> +Required Properties:
> >> +- compatible: should be one of the following
> >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
> >> + Must provide a second register area and marvell,pad-type.
> >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
> >> + Armada-3700.
> >
> > Need SoC specific compatible strings.
> >
>
> Xenon SDHC is a common IP for all Marvell SOCs.
> It is difficult to use a single SOC specific compatible to represent Xenon SDHC.
> There will be so many SOC compatible strings in list if each specific SOC owns a compatible.
> Actually only few SOCs require special properties.
> Any suggestion please?
>
> >> +
> >> +- clocks:
> >> + Array of clocks required for SDHCI.
> >> + Requires at least one for Xenon IP core.
> >> + Some SOCs require additional clock for AXI bus.
> >> +
> >> +- clock-names:
> >> + Array of names corresponding to clocks property.
> >> + The input clock for Xenon IP core should be named as "core".
> >> + The optional AXI clock should be named as "axi".
> >
> > When is AXI clock optional? This should be required for ?? compatible
> > strings.
> >
> It is required on some SOCs.
> I will double check if a suitable compatible string can be determined for those SOCs.
Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two
solutions:
solA: as current patch does, take "marvell,xenon-sdhci" as compatible string
and make the AXI clock property optional. Usually for berlin SoCs, we don't need
special properties.
PS: this solution is also what sdhci-pxav3.c takes
solB: As Rob said, add extra SoC compatible strings, so we'll have
something like:
static const struct of_device_id sdhci_xenon_of_match[] = {
{ .compatible = "marvell,armada-3700-sdhci", },
{ .compatible = "marvell,berlin4ct-sdhci", },
...
{ .compatible = "marvell,berlinxxx-mmc", },
}
then we take care the AXI clk for berlin SoCs in the code.
Which solution do you prefer?
Thanks,
Jisheng
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: wlf @ 2016-11-11 3:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2283070.Hkeafucara@diego>
Hi Heiko?
? 2016?11?10? 17:21, Heiko St?bner ??:
> Am Donnerstag, 10. November 2016, 10:54:49 schrieb wlf:
>> Hi Doug,
>>
>> ? 2016?11?10? 04:54, Doug Anderson ??:
>>> Hi,
>>>
>>> On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> wrote:
>>>> We found that the system crashed due to 480MHz output clock of
>>>> USB2 PHY was unstable after clock had been enabled by gpu module.
>>>>
>>>> Theoretically, 1 millisecond is a critical value for 480MHz
>>>> output clock stable time, so we try to change the delay time
>>>> to 1.2 millisecond to avoid this issue.
>>>>
>>>> Signed-off-by: William Wu <wulf@rock-chips.com>
>>>> ---
>>>>
>>>> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
>>>> b/drivers/phy/phy-rockchip-inno-usb2.c index ecfd7d1..8f2d2b6 100644
>>>> --- a/drivers/phy/phy-rockchip-inno-usb2.c
>>>> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
>>>> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct
>>>> clk_hw *hw)>>
>>>> return ret;
>>>>
>>>> /* waitting for the clk become stable */
>>>>
>>>> - mdelay(1);
>>>> + udelay(1200);
>>> Several people who have seen this patch have expressed concern that a
>>> 1.2 ms delay is pretty long for something that's supposed to be
>>> "atomic" like a clk_enable(). Consider that someone might call
>>> clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
>>> latency is not so great.
>>>
>>> It seems like this clock should be moved to be enabled in "prepare"
>>> and the "enable" should be a no-op. This is a functionality change,
>>> but I don't think there are any real users for this clock at the
>>> moment so it should be fine.
>>>
>>> (of course, the 1 ms latency that existed before this patch was still
>>> pretty bad, but ...)
>> Thanks a lot for your suggestion.
>> I agree with you. clk_enable() will call spin_lock_irqsave() to disable
>> interrupt, and we add
>> more than 1ms in clk_enable may cause big latency.
>>
>> And according to clk_prepare() description:
>> In a simple case, clk_prepare can be used instead of clk_enable to
>> ungate a clk if the
>> operation may sleep. One example is a clk which is accessed over I2c.
>>
>> So maybe we can remove the clock to clk_prepare.
>>
>> Hi Heiko, Frank,
>> What do you think of it?
> moving to clk_prepare sounds sensible. That way you can switch from delay to
> sleep functions as well.
Thanks very much.
I will try to update a new patch.
Best regards,
Wulf
>
>
> Heiko
>
>
>
^ permalink raw reply
* [PATCH 0/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-11-11 3:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lee,
Recently we've added full SPL support for A80 to mainline U-boot. This
means we no longer depend on Allwinner's bootloader. It also means that
some of system configuration the bootloader set up no longer applies.
The bootloader was correctly configuring the multi-device addressing
support in the AXP806 PMIC. If the PMIC is not correctly addressed, it
just ignores all reads and writes to the other registers. As mainline
U-boot does not support the AXP806, and since we can't always count on
a good bootloader, we should re-configure this in the kernel regardless.
Patch 1 adds the registers for the multi-device addressing scheme to
the AXP806 regmap.
Patch 2 configures the register at probe time, and reinitializes the
regmap cache.
Since support for this PMIC was just added in 4.9-rc1, I hope you can
merge these 2 patches as fixes for 4.9.
Thank you!
Regards
ChenYu
Chen-Yu Tsai (2):
mfd: axp20x: Add address extension registers for AXP806 regmap
mfd: axp20x: Fix AXP806 access errors on cold boot
drivers/mfd/axp20x.c | 38 +++++++++++++++++++++++++++++++++++++-
include/linux/mfd/axp20x.h | 2 ++
2 files changed, 39 insertions(+), 1 deletion(-)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] mfd: axp20x: Add address extension registers for AXP806 regmap
From: Chen-Yu Tsai @ 2016-11-11 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111032953.20849-1-wens@csie.org>
The AXP806 supports either master/standalone or slave mode.
Slave mode allows sharing the serial bus, even with multiple
AXP806 which all have the same hardware address.
This is done with extra "serial interface address extension",
or AXP806_BUS_ADDR_EXT, and "register address extension", or
AXP806_REG_ADDR_EXT, registers. The former is read-only, with
1 bit customizable at the factory, and 1 bit depending on the
state of an external pin. The latter is writable. Only when
the these device addressing bits (in the upper 4 bits of the
registers) match, will the device respond to operations on
its other registers.
Add these 2 registers to the regmap so we can access them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/mfd/axp20x.c | 3 ++-
include/linux/mfd/axp20x.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be32e61..cdaeb34a9a38 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -135,6 +135,7 @@ static const struct regmap_range axp806_writeable_ranges[] = {
regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+ regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
};
static const struct regmap_range axp806_volatile_ranges[] = {
@@ -305,7 +306,7 @@ static const struct regmap_config axp806_regmap_config = {
.val_bits = 8,
.wr_table = &axp806_writeable_table,
.volatile_table = &axp806_volatile_table,
- .max_register = AXP806_VREF_TEMP_WARN_L,
+ .max_register = AXP806_REG_ADDR_EXT,
.cache_type = REGCACHE_RBTREE,
};
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index fec597fb34cb..7e85ececcedf 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -115,6 +115,8 @@ enum {
#define AXP806_CLDO2_V_CTRL 0x25
#define AXP806_CLDO3_V_CTRL 0x26
#define AXP806_VREF_TEMP_WARN_L 0xf3
+#define AXP806_BUS_ADDR_EXT 0xfe
+#define AXP806_REG_ADDR_EXT 0xff
/* Interrupt */
#define AXP152_IRQ1_EN 0x40
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-11-11 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111032953.20849-1-wens@csie.org>
The AXP806 supports either master/standalone or slave mode.
Slave mode allows sharing the serial bus, even with multiple
AXP806 which all have the same hardware address.
This is done with extra "serial interface address extension",
or AXP806_BUS_ADDR_EXT, and "register address extension", or
AXP806_REG_ADDR_EXT, registers. The former is read-only, with
1 bit customizable at the factory, and 1 bit depending on the
state of an external pin. The latter is writable. Only when
the these device addressing bits (in the upper 4 bits of the
registers) match, will the device respond to operations on
its other registers.
The AXP806_REG_ADDR_EXT was previously configured by Allwinner's
bootloader. Work on U-boot SPL support now allows us to switch
to mainline U-boot, which doesn't do this for us. There might
be other bare minimum bootloaders out there which don't to this
either. It's best to handle this in the kernel.
This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
know to be the proper value for a standard AXP806 in slave mode.
Afterwards it will reinitialize the regmap cache, to purge any
invalid stale values.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/mfd/axp20x.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cdaeb34a9a38..2f5d46f28511 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -829,6 +829,41 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
{
int ret;
+ /*
+ * The AXP806 supports either master/standalone or slave mode.
+ * Slave mode allows sharing the serial bus, even with multiple
+ * AXP806 which all have the same hardware address.
+ *
+ * This is done with extra "serial interface address extension",
+ * or AXP806_BUS_ADDR_EXT, and "register address extension", or
+ * AXP806_REG_ADDR_EXT, registers. The former is read-only, with
+ * 1 bit customizable at the factory, and 1 bit depending on the
+ * state of an external pin. The latter is writable. Only when
+ * the these device addressing bits (in the upper 4 bits of the
+ * registers) match, will the device respond to operations on its
+ * other registers.
+ *
+ * Since we only support an AXP806 chained to an AXP809 in slave
+ * mode, and there isn't any existing hardware which uses AXP806
+ * in master mode, or has 2 AXP806s in the same system, we can
+ * just program the register address extension to the slave mode
+ * address.
+ */
+ if (axp20x->variant == AXP806_ID) {
+ /* Write to the register address extension register */
+ regmap_write(axp20x->regmap, AXP806_REG_ADDR_EXT, 0x10);
+
+ /* Make sure the write hits the device */
+ regcache_sync_region(axp20x->regmap, AXP806_REG_ADDR_EXT,
+ AXP806_REG_ADDR_EXT);
+
+ /*
+ * Reinitialize the regmap cache in case the device didn't
+ * properly respond to our reads before.
+ */
+ regmap_reinit_cache(axp20x->regmap, axp20x->regmap_cfg);
+ }
+
ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
IRQF_ONESHOT | IRQF_SHARED, -1,
axp20x->regmap_irq_chip,
--
2.10.2
^ permalink raw reply related
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-11-11 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b7232421-10f7-2bac-0ad8-847804126bf2@ti.com>
> On Nov 9, 2016, at 9:07 PM, Vignesh R <vigneshr@ti.com> wrote:
>
> Hi,
>
> On Thursday 10 November 2016 05:23 AM, John Syne wrote:
>> OK, then back to my original question. Given that these DT properties are supported in the driver
>>
>
> Below properties are supported by only by ti_am3335x_adc driver and not
> ti_am335x_tsc driver. As author of this patch pointed out in another
> reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
> see a use case where these values needs to be tweaked for tsc channels,
> therefore it does not make sense to be DT properties.
Yeah, the confusion was mine because the author of this patch series was proposing to hard code these settings while DT properties already existed in the ti_am335x_adc driver. I use the ADC for sensor measurement and do not use the touchscreen features. I already pointed out where these DT parameters should be added by referencing how this was done in one of the BBB DT overlay files [1]. I am just proposing the same is done as a default in the AM33xx.dtsi and AM4372.dtsi files. Here is what I was proposing. Granted, the adc-channels should be restricted to the subset of channels not used by tsc, but you get the idea.
tscadc: tscadc at 44e0d000 {
compatible = "ti,am3359-tscadc";
reg = <0x44e0d000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <16>;
ti,hwmods = "adc_tsc";
status = "disabled";
dmas = <&edma 53 0>, <&edma 57 0>;
dma-names = "fifo0", "fifo1?;
tsc {
compatible = "ti,am3359-tsc";
};
am335x_adc: adc {
#io-channel-cells = <1>;
ti,adc-channels = <0 1 2 3 4 5 6>;
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
compatible = "ti,am3359-adc";
};
};
[1]https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
Regards,
John
>
>> shouldn?t the following be added to am33xx.dtsi and am4372.dtsi?
>
> Its totally upto board dts files to allocate channels for tsc and adc.
> So, how could these be added to dtsi files?
>
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>
>> Regards,
>> John
>>>
>>> --
>>> Regards
>>> Vignesh
>>
>
> --
> Regards
> Vignesh
^ permalink raw reply
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Jisheng Zhang @ 2016-11-11 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111112243.7431625d@xhacker>
On Fri, 11 Nov 2016 11:22:43 +0800 Jisheng Zhang wrote:
> Hi Rob, Ziji,
>
> On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote:
>
> > Hi Rob,
> >
> > On 2016/11/10 2:24, Rob Herring wrote:
> > > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
> > >> From: Ziji Hu <huziji@marvell.com>
> > >>
> > >> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> > >> Add Xenon-specific properties.
> > >> Also add properties for Xenon PHY setting.
> > >>
> > >> Signed-off-by: Hu Ziji <huziji@marvell.com>
> > >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > >> ---
> > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
> > >> MAINTAINERS | 1 +-
> > >> 2 files changed, 162 insertions(+), 0 deletions(-)
> > >> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >> new file mode 100644
> > >> index 000000000000..0d2d139494d3
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >> @@ -0,0 +1,161 @@
> > >> +Marvell's Xenon SDHCI Controller device tree bindings
> > >> +This file documents differences between the core mmc properties
> > >> +described by mmc.txt and the properties used by the Xenon implementation.
> > >> +
> > >> +A single Xenon IP can support multiple slots.
> > >> +Each slot acts as an independent SDHC. It owns independent resources, such
> > >> +as register sets clock and PHY.
> > >> +Each slot should have an independent device tree node.
> > >> +
> > >> +Required Properties:
> > >> +- compatible: should be one of the following
> > >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
> > >> + Must provide a second register area and marvell,pad-type.
> > >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
> > >> + Armada-3700.
> > >
> > > Need SoC specific compatible strings.
> > >
> >
> > Xenon SDHC is a common IP for all Marvell SOCs.
> > It is difficult to use a single SOC specific compatible to represent Xenon SDHC.
> > There will be so many SOC compatible strings in list if each specific SOC owns a compatible.
> > Actually only few SOCs require special properties.
> > Any suggestion please?
> >
> > >> +
> > >> +- clocks:
> > >> + Array of clocks required for SDHCI.
> > >> + Requires at least one for Xenon IP core.
> > >> + Some SOCs require additional clock for AXI bus.
> > >> +
> > >> +- clock-names:
> > >> + Array of names corresponding to clocks property.
> > >> + The input clock for Xenon IP core should be named as "core".
> > >> + The optional AXI clock should be named as "axi".
> > >
> > > When is AXI clock optional? This should be required for ?? compatible
> > > strings.
> > >
> > It is required on some SOCs.
> > I will double check if a suitable compatible string can be determined for those SOCs.
>
> Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two
> solutions:
>
> solA: as current patch does, take "marvell,xenon-sdhci" as compatible string
> and make the AXI clock property optional. Usually for berlin SoCs, we don't need
> special properties.
Personally, I prefer solA: use the IP name as compatible string. This is IP
specific rather than SoC specific. The HW itself supports two clks
Thanks,
Jisheng
>
> PS: this solution is also what sdhci-pxav3.c takes
>
> solB: As Rob said, add extra SoC compatible strings, so we'll have
> something like:
>
> static const struct of_device_id sdhci_xenon_of_match[] = {
> { .compatible = "marvell,armada-3700-sdhci", },
> { .compatible = "marvell,berlin4ct-sdhci", },
> ...
> { .compatible = "marvell,berlinxxx-mmc", },
> }
>
> then we take care the AXI clk for berlin SoCs in the code.
>
>
> Which solution do you prefer?
>
> Thanks,
> Jisheng
^ permalink raw reply
* No subject
From: Chunyan Zhang @ 2016-11-11 3:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Steven,
On 21 October 2016 at 20:13, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 18 Oct 2016 16:08:58 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>
>> This is getting better, but I still have some nits.
>>
>
> Thanks.
>
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>> include/linux/trace.h | 28 +++++++++++
>>> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 159 insertions(+), 1 deletion(-)
>>> create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..eb1c5b8
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next - pointer to the next trace_export
>>> + * write - copy traces which have been delt with ->commit() to
>>> + * the destination
>>> + */
>>> +struct trace_export {
>>> + struct trace_export __rcu *next;
>>> + void (*write)(const char *, unsigned int);
>>
>> Why const char*? Why not const void *? This will never be a string.
>>
>
> Will revise this.
>
>>
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif /* CONFIG_TRACING */
>>> +
>>> +#endif /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..db94ec1 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/poll.h>
>>> #include <linux/nmi.h>
>>> #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>> #include <linux/sched/rt.h>
>>>
>>> #include "trace.h"
>>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>> ftrace_trace_userstack(buffer, flags, pc);
>>> }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> + struct ring_buffer_event *event)
>>> +{
>>> + struct trace_entry *entry;
>>> + unsigned int size = 0;
>>> +
>>> + entry = ring_buffer_event_data(event);
>>> +
>>> + size = ring_buffer_event_length(event);
>>> +
>>> + if (export->write)
>>> + export->write((char *)entry, size);
>>
>> Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
>>
>> And if there is, this can be racy. As in
>>
>>
>> CPU 0: CPU 1:
>> ------ ------
>> if (export->write)
>>
>> export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
Any further comments? :)
Thanks,
Chunyan
>
> Thanks for the review,
> Chunyan
>
>>
>> export->write(entry, size);
>>
>> BOOM!
>>
>>
>> -- Steve
>>
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> + static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> + static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>> +{
>>> + struct trace_export *export;
>>> +
>>> + preempt_disable_notrace();
>>> +
>>> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> + while (export) {
>>> + trace_process_export(export, event);
>>> + export = rcu_dereference_raw_notrace(export->next);
>>> + }
>>> +
>>> + preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + rcu_assign_pointer(export->next, *list);
>>> + /*
>>> + * We are entering export into the list but another
>>> + * CPU might be walking that list. We need to make sure
>>> + * the export->next pointer is valid before another CPU sees
>>> + * the export pointer included into the list.
>>> + */
>>> + rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + struct trace_export **p;
>>> +
>>> + for (p = list; *p != NULL; p = &(*p)->next)
>>> + if (*p == export)
>>> + break;
>>> +
>>> + if (*p != export)
>>> + return -1;
>>> +
>>> + rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + if (*list == NULL)
>>> + ftrace_exports_enable();
>>> +
>>> + add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + ret = rm_trace_export(list, export);
>>> + if (*list == NULL)
>>> + ftrace_exports_disable();
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> + if (WARN_ON_ONCE(!export->write))
>>> + return -1;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>> void
>>> trace_function(struct trace_array *tr,
>>> unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2273,11 @@ trace_function(struct trace_array *tr,
>>> entry->ip = ip;
>>> entry->parent_ip = parent_ip;
>>>
>>> - if (!call_filter_check_discard(call, entry, buffer, event))
>>> + if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> + if (static_branch_unlikely(&ftrace_exports_enabled))
>>> + ftrace_exports(event);
>>> __buffer_unlock_commit(buffer, event);
>>> + }
>>> }
>>>
>>> #ifdef CONFIG_STACKTRACE
>>
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Javier Martinez Canillas @ 2016-11-11 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66H1doBOdPPN9kz1vdNYx8gpgkF6s3UhTiXCCp0RZYKwg@mail.gmail.com>
Hello ChenYu
On Fri, Nov 11, 2016 at 12:01 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring <robh@kernel.org> wrote:
[snip]
>>
>> Do you have patches using this already. If not, it is starting to get
>> a bit late for v4.10.
>>
>> I can apply this, but then you'll just be pulling in other DT patches.
>
> Not sure what you mean by "using" this...
>
> I have patches which use this to add DT-based modalias entries for
> module auto-loading to i2c and sunxi-rsb that I haven't sent.
>
Unfortunately the I2C core can't be changed without breaking a lot of
I2C drivers that are relying on the current behavior. I've already
posted a RFC patch [0] for I2C that does this about a year ago and
enumerated the issues that have to be addressed before the change can
be made (and fixed some of the issues mentioned) on this series [1].
Another issue is that an I2C device ID table is a requirement anyways
since I2C drivers expect an i2c_device_id as an argument of their
probe function. Kieran already have patches [2] to change that which
should land soon.
I plan to fix the remaining I2C drivers once his patches are merged
and re-post the RFC patch as a proper one.
> As far as DT usage goes, we already need this for the axp20x mfd driver.
> There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was
> sent to fix module auto-loading by using the I2C client ID table:
>
> mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
> https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=b7142a19321484bd7681aa547c1d50148c8e2825
>
Yes, this is the workaround used by most DT-only I2C drivers. The only
reason that these drivers have an I2C device ID is due the
restrictions imposed by the I2C core.
Best regards,
Javier
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Stefan Agner @ 2016-11-11 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7eb3df71-6d1a-006a-cc4c-83ff8df3c42c@mentor.com>
On 2016-11-10 10:29, Vladimir Zapolskiy wrote:
> Hi Stefan, Philipp,
>
> On 11/09/2016 02:50 AM, Stefan Agner wrote:
>> On 2016-11-08 09:33, maitysanchayan at gmail.com wrote:
>>> Hello Shawn,
>>>
>>> On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
>>>> Hi Shawn,
>>>>
>>>> On 10/22/2016 06:25 AM, Shawn Guo wrote:
>>>>> On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
>>>>>> Remove the use of DDC I2C bus bitbang to support reading of EDID
>>>>>> and rely on support from internal HDMI I2C master controller instead.
>>>>>> As a result remove the device tree property ddc-i2c-bus.
>>>>>>
>>>>>> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>>>>>
>>>>> I think that the dw-hdmi i2c support [1] is a prerequisite of this
>>>>> patch. I do not see it lands on v4.9-rc1. Or am I missing something?
>>>>>
>>>>> Shawn
>>>>>
>>>>> [1] https://patchwork.kernel.org/patch/9296883/
>>>>>
>>>>
>>>> I'm adding Philipp to Cc, since he is the last one who tested the change
>>>> and helped me to push the change to the mainline:
>>>>
>>>> https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
>>>>
>>>> The problem is that there is no official DW HDMI bridge maintainer, may be
>>>> you can review the change, and if you find it satisfactory push it through
>>>> ARM/iMX tree.
>>>
>>> Shawn, is it okay if that patch goes through your ARM/iMX tree?
>>
>> I don't think it makes sense that the DRM bridge changes go through
>> Shawn's tree. Dave should merge Philipps pull request...
>>
>
> Philipp, do you mind to submit a rebased pull request one more time?
>
You probably saw it, Dave merged it today in his drm-next branch:
https://cgit.freedesktop.org/~airlied/linux/?h=drm-next
I guess with that Shawn can go ahead and merge this patchset for next
too...?
--
Stefan
^ permalink raw reply
* [PATCH v16 0/5] Mediatek MT8173 CMDQ support
From: Jassi Brar @ 2016-11-11 5:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478776558.15447.2.camel@mtksdaap41>
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.
^ permalink raw reply
* [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Archit Taneja @ 2016-11-11 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFqH_52A4=GubRjPa8X1=STExXFZy2HdoASEGUBYwqGt0BEFcw@mail.gmail.com>
Hi Jitao,
I couldn't locate the original mail, so posting on this thread instead.
Some comments below.
On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote:
> Hi Jitao,
>
> 2016-08-27 8:44 GMT+02:00 Jitao Shi <jitao.shi@mediatek.com>:
>> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>>
>> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
>> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
>> ---
>> Changes since v16:
>> - Disable ps8640 DSI MCS Function.
>> - Rename gpios name more clearly.
>> - Tune the ps8640 power on sequence.
>>
>> Changes since v15:
>> - Drop drm_connector_(un)register calls from parade ps8640.
>> The main DRM driver mtk_drm_drv now calls
>> drm_connector_register_all() after drm_dev_register() in the
>> mtk_drm_bind() function. That function should iterate over all
>> connectors and call drm_connector_register() for each of them.
>> So, remove drm_connector_(un)register calls from parade ps8640.
>>
>> Changes since v14:
>> - update copyright info.
>> - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
>> - fix some coding style.
>> - use sizeof as array counter.
>> - use drm_get_edid when read edid.
>> - add mutex when firmware updating.
>>
>> Changes since v13:
>> - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len)
>> - fix PAGE2_SW_REST tyro.
>> - move the buf[3] init to entrance of the function.
>>
>> Changes since v12:
>> - fix hw_chip_id build warning
>>
>> Changes since v11:
>> - Remove depends on I2C, add DRM depends
>> - Reuse ps8640_write_bytes() in ps8640_write_byte()
>> - Use timer check for polling like the routines in <linux/iopoll.h>
>> - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail
>> - Check the ps8640 hardware id in ps8640_validate_firmware
>> - Remove fw_version check
>> - Move ps8640_validate_firmware before ps8640_enter_bl
>> - Add ddc_i2c unregister when probe fail and ps8640_remove
>> ---
>> drivers/gpu/drm/bridge/Kconfig | 12 +
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> drivers/gpu/drm/bridge/parade-ps8640.c | 1077 ++++++++++++++++++++++++++++++++
>> 3 files changed, 1090 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index b590e67..c59d043 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
>> ---help---
>> Parade eDP-LVDS bridge chip driver.
>>
>> +config DRM_PARADE_PS8640
>> + tristate "Parade PS8640 MIPI DSI to eDP Converter"
>> + depends on DRM
>> + depends on OF
>> + select DRM_KMS_HELPER
>> + select DRM_MIPI_DSI
>> + select DRM_PANEL
>> + ---help---
>> + Choose this option if you have PS8640 for display
>> + The PS8640 is a high-performance and low-power
>> + MIPI DSI to eDP converter
>> +
>> config DRM_SII902X
>> tristate "Silicon Image sii902x RGB/HDMI bridge"
>> depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>> index efdb07e..3360537 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
>> obj-$(CONFIG_DRM_SII902X) += sii902x.o
>> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
>> new file mode 100644
>> index 0000000..7d67431
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -0,0 +1,1077 @@
>> +/*
>> + * Copyright (c) 2016 MediaTek Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/firmware.h>
>> +#include <linux/gpio.h>
Not needed.
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_gpio.h>
The above 2 aren't needed.
>> +#include <linux/of_graph.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <asm/unaligned.h>
>> +#include <drm/drm_panel.h>
>> +
>> +#include <drmP.h>
>> +#include <drm_atomic_helper.h>
>> +#include <drm_crtc_helper.h>
>> +#include <drm_crtc.h>
Not needed.
>> +#include <drm_edid.h>
>> +#include <drm_mipi_dsi.h>
>> +
>> +#define PAGE1_VSTART 0x6b
>> +#define PAGE2_SPI_CFG3 0x82
>> +#define I2C_TO_SPI_RESET 0x20
>> +#define PAGE2_ROMADD_BYTE1 0x8e
>> +#define PAGE2_ROMADD_BYTE2 0x8f
>> +#define PAGE2_SWSPI_WDATA 0x90
>> +#define PAGE2_SWSPI_RDATA 0x91
>> +#define PAGE2_SWSPI_LEN 0x92
>> +#define PAGE2_SWSPI_CTL 0x93
>> +#define TRIGGER_NO_READBACK 0x05
>> +#define TRIGGER_READBACK 0x01
>> +#define PAGE2_SPI_STATUS 0x9e
>> +#define SPI_READY 0x0c
>> +#define PAGE2_GPIO_L 0xa6
>> +#define PAGE2_GPIO_H 0xa7
>> +#define PS_GPIO9 BIT(1)
>> +#define PAGE2_IROM_CTRL 0xb0
>> +#define IROM_ENABLE 0xc0
>> +#define IROM_DISABLE 0x80
>> +#define PAGE2_SW_RESET 0xbc
>> +#define SPI_SW_RESET BIT(7)
>> +#define MPU_SW_RESET BIT(6)
>> +#define PAGE2_ENCTLSPI_WR 0xda
>> +#define PAGE2_I2C_BYPASS 0xea
>> +#define I2C_BYPASS_EN 0xd0
>> +#define PAGE2_MCS_EN 0xf3
>> +#define MCS_EN BIT(0)
>> +#define PAGE3_SET_ADD 0xfe
>> +#define PAGE3_SET_VAL 0xff
>> +#define VDO_CTL_ADD 0x13
>> +#define VDO_DIS 0x18
>> +#define VDO_EN 0x1c
>> +#define PAGE4_REV_L 0xf0
>> +#define PAGE4_REV_H 0xf1
>> +#define PAGE4_CHIP_L 0xf2
>> +#define PAGE4_CHIP_H 0xf3
>> +
>> +/* Firmware */
>> +#define PS_FW_NAME "ps864x_fw.bin"
>> +
>
> About the firmware discussion I think that if you want to maintain the
> upgrade firmware thing you should also include this patch in the
> series.
>
> https://chromium-review.googlesource.com/#/c/317221/
>
> Otherwise, if this is not really needed I think that remove this from
> the driver is the best. Just an opinion, this is something the
> maintainer should decide.
Was there a conclusion on this? As Daniel Kurtz suggested, can we drop
the update firmware stuff for now and try to get the functional part
for 4.10?
>
>> +#define FW_CHIP_ID_OFFSET 0
>> +#define FW_VERSION_OFFSET 2
>> +#define EDID_I2C_ADDR 0x50
>> +
>> +#define WRITE_STATUS_REG_CMD 0x01
>> +#define READ_STATUS_REG_CMD 0x05
>> +#define BUSY BIT(0)
>> +#define CLEAR_ALL_PROTECT 0x00
>> +#define BLK_PROTECT_BITS 0x0c
>> +#define STATUS_REG_PROTECT BIT(7)
>> +#define WRITE_ENABLE_CMD 0x06
>> +#define CHIP_ERASE_CMD 0xc7
>> +#define MAX_DEVS 0x8
>> +
>> +struct ps8640_info {
>> + u8 family_id;
>> + u8 variant_id;
>> + u16 version;
>> +};
>> +
>> +struct ps8640 {
>> + struct drm_connector connector;
>> + struct drm_bridge bridge;
>> + struct edid *edid;
>> + struct mipi_dsi_device dsi;
>> + struct i2c_client *page[MAX_DEVS];
>> + struct i2c_client *ddc_i2c;
>> + struct regulator_bulk_data supplies[2];
>> + struct drm_panel *panel;
>> + struct gpio_desc *gpio_reset;
>> + struct gpio_desc *gpio_power_down;
>> + struct gpio_desc *gpio_mode_sel;
>> + bool enabled;
>> +
>> + /* firmware file info */
>> + struct ps8640_info info;
>> + bool in_fw_update;
>> + /* for firmware update protect */
>> + struct mutex fw_mutex;
>> +};
>> +
>> +static const u8 enc_ctrl_code[6] = { 0xaa, 0x55, 0x50, 0x41, 0x52, 0x44 };
>> +static const u8 hw_chip_id[4] = { 0x00, 0x0a, 0x00, 0x30 };
>> +
>> +static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> +{
>> + return container_of(e, struct ps8640, bridge);
>> +}
>> +
>> +static inline struct ps8640 *connector_to_ps8640(struct drm_connector *e)
>> +{
>> + return container_of(e, struct ps8640, connector);
>> +}
>> +
>> +static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
>> + u16 data_len)
>> +{
>> + int ret;
>> + struct i2c_msg msgs[] = {
>> + {
>> + .addr = client->addr,
>> + .flags = 0,
>> + .len = 1,
>> + .buf = ®,
>> + },
>> + {
>> + .addr = client->addr,
>> + .flags = I2C_M_RD,
>> + .len = data_len,
>> + .buf = data,
>> + }
>> + };
>> +
>> + ret = i2c_transfer(client->adapter, msgs, 2);
>> +
>> + if (ret == 2)
>> + return 0;
>> + if (ret < 0)
>> + return ret;
>> + else
>> + return -EIO;
>> +}
>> +
>> +static int ps8640_write_bytes(struct i2c_client *client, const u8 *data,
>> + u16 data_len)
>> +{
>> + int ret;
>> + struct i2c_msg msg;
>> +
>> + msg.addr = client->addr;
>> + msg.flags = 0;
>> + msg.len = data_len;
>> + msg.buf = (u8 *)data;
>> +
>> + ret = i2c_transfer(client->adapter, &msg, 1);
>> + if (ret == 1)
>> + return 0;
>> + if (ret < 0)
>> + return ret;
>> + else
>> + return -EIO;
>> +}
>> +
>> +static int ps8640_write_byte(struct i2c_client *client, u8 reg, u8 data)
>> +{
>> + u8 buf[] = { reg, data };
>> +
>> + return ps8640_write_bytes(client, buf, sizeof(buf));
>> +}
>> +
>> +static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[5];
>> + u8 fw_ver[2];
>> +
>> + ps8640_read(client, 0x4, fw_ver, sizeof(fw_ver));
>> + ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
>> +
>> + DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
>> +}
>> +
>> +static int ps8640_bridge_unmute(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[3];
>> + u8 vdo_ctrl_buf[3] = { PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN };
>> +
>> + return ps8640_write_bytes(client, vdo_ctrl_buf, sizeof(vdo_ctrl_buf));
>> +}
>> +
>> +static int ps8640_bridge_mute(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[3];
>> + u8 vdo_ctrl_buf[3] = { PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS };
>> +
>> + return ps8640_write_bytes(client, vdo_ctrl_buf, sizeof(vdo_ctrl_buf));
>> +}
>> +
>> +static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +{
>> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> + struct i2c_client *client = ps_bridge->page[2];
>> + struct i2c_client *page1 = ps_bridge->page[1];
It's a bit hard to follow what page[3] or page[5] means without going to the
bottom and reading the dummy devices comment. It would be nice to have some
macros here.
>> + int err;
>> + u8 set_vdo_done, mcs_en, vstart;
>> + ktime_t timeout;
>> +
>> + if (ps_bridge->in_fw_update)
>> + return;
>> +
>> + if (ps_bridge->enabled)
>> + return;
>> +
>> + err = drm_panel_prepare(ps_bridge->panel);
>> + if (err < 0) {
>> + DRM_ERROR("failed to prepare panel: %d\n", err);
>> + return;
>> + }
>> +
>> + err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>> + ps_bridge->supplies);
>> + if (err < 0) {
>> + DRM_ERROR("cannot enable regulators %d\n", err);
>> + goto err_panel_unprepare;
>> + }
>> +
>> + gpiod_set_value(ps_bridge->gpio_power_down, 1);
>> + gpiod_set_value(ps_bridge->gpio_reset, 0);
>> + usleep_range(2000, 2500);
>> + gpiod_set_value(ps_bridge->gpio_reset, 1);
>> +
>> + /*
>> + * Wait for the ps8640 embed mcu ready
>> + * First wait 200ms and then check the mcu ready flag every 20ms
>> + */
>> + msleep(200);
>> +
>> + timeout = ktime_add_ms(ktime_get(), 200);
>> + for (;;) {
>> + err = ps8640_read(client, PAGE2_GPIO_H, &set_vdo_done, 1);
>> + if (err < 0) {
>> + DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", err);
>> + goto err_regulators_disable;
>> + }
>> + if ((set_vdo_done & PS_GPIO9) == PS_GPIO9)
>> + break;
>> + if (ktime_compare(ktime_get(), timeout) > 0)
>> + break;
>> + msleep(20);
>> + }
>> +
>> + msleep(50);
>> +
>> + ps8640_read(page1, PAGE1_VSTART, &vstart, 1);
>> + DRM_INFO("PS8640 PAGE1.0x6B = 0x%x\n", vstart);
>> +
>> + /**
>> + * The Manufacturer Command Set (MCS) is a device dependent interface
>> + * intended for factory programming of the display module default
>> + * parameters. Once the display module is configured, the MCS shall be
>> + * disabled by the manufacturer. Once disabled, all MCS commands are
>> + * ignored by the display interface.
>> + */
>> + ps8640_read(client, PAGE2_MCS_EN, &mcs_en, 1);
>> + ps8640_write_byte(client, PAGE2_MCS_EN, mcs_en & ~MCS_EN);
>> +
>> + if (ps_bridge->info.version == 0)
>> + ps8640_get_mcu_fw_version(ps_bridge);
>> +
>> + err = ps8640_bridge_unmute(ps_bridge);
>> + if (err)
>> + DRM_ERROR("failed to enable unmutevideo: %d\n", err);
>> + /* Switch access edp panel's edid through i2c */
>> + ps8640_write_byte(client, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
>> + ps_bridge->enabled = true;
>> +
>> + return;
>> +
>> +err_regulators_disable:
>> + regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
>> + ps_bridge->supplies);
>> +err_panel_unprepare:
>> + drm_panel_unprepare(ps_bridge->panel);
>> +}
>> +
>> +static void ps8640_enable(struct drm_bridge *bridge)
>> +{
>> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> + int err;
>> +
>> + err = drm_panel_enable(ps_bridge->panel);
>> + if (err < 0)
>> + DRM_ERROR("failed to enable panel: %d\n", err);
>> +}
>> +
>> +static void ps8640_disable(struct drm_bridge *bridge)
>> +{
>> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> + int err;
>> +
>> + err = drm_panel_disable(ps_bridge->panel);
>> + if (err < 0)
>> + DRM_ERROR("failed to disable panel: %d\n", err);
>> +}
>> +
>> +static void ps8640_post_disable(struct drm_bridge *bridge)
>> +{
>> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> + int err;
>> +
>> + if (ps_bridge->in_fw_update)
>> + return;
>> +
>> + if (!ps_bridge->enabled)
>> + return;
>> +
>> + ps_bridge->enabled = false;
>> +
>> + err = ps8640_bridge_mute(ps_bridge);
>> + if (err < 0)
>> + DRM_ERROR("failed to unmutevideo: %d\n", err);
>> +
>> + gpiod_set_value(ps_bridge->gpio_reset, 0);
>> + gpiod_set_value(ps_bridge->gpio_power_down, 0);
>> + err = regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
>> + ps_bridge->supplies);
>> + if (err < 0)
>> + DRM_ERROR("cannot disable regulators %d\n", err);
>> +
>> + err = drm_panel_unprepare(ps_bridge->panel);
>> + if (err)
>> + DRM_ERROR("failed to unprepare panel: %d\n", err);
>> +}
>> +
>> +static int ps8640_get_modes(struct drm_connector *connector)
>> +{
>> + struct ps8640 *ps_bridge = connector_to_ps8640(connector);
>> + struct edid *edid;
>> + int num_modes = 0;
>> + bool power_off;
>> +
>> + if (ps_bridge->edid)
>> + return drm_add_edid_modes(connector, ps_bridge->edid);
>> +
>> + power_off = !ps_bridge->enabled;
>> + ps8640_pre_enable(&ps_bridge->bridge);
>> +
>> + edid = drm_get_edid(connector, ps_bridge->ddc_i2c->adapter);
See comments related to this in ps8640_probe.
>> + if (!edid)
>> + goto out;
>> +
>> + ps_bridge->edid = edid;
>> + drm_mode_connector_update_edid_property(connector, ps_bridge->edid);
>> + num_modes = drm_add_edid_modes(connector, ps_bridge->edid);
>> +
>> +out:
>> + if (power_off)
>> + ps8640_post_disable(&ps_bridge->bridge);
>> +
>> + return num_modes;
>> +}
>> +
>> +static struct drm_encoder *ps8640_best_encoder(struct drm_connector *connector)
>> +{
>> + struct ps8640 *ps_bridge = connector_to_ps8640(connector);
>> +
>> + return ps_bridge->bridge.encoder;
>> +}
We can drop the above func.
>> +
>> +static const struct drm_connector_helper_funcs ps8640_connector_helper_funcs = {
>> + .get_modes = ps8640_get_modes,
>> + .best_encoder = ps8640_best_encoder,
>> +};
>> +
>> +static enum drm_connector_status ps8640_detect(struct drm_connector *connector,
>> + bool force)
>> +{
>> + return connector_status_connected;
>> +}
>> +
>> +static const struct drm_connector_funcs ps8640_connector_funcs = {
>> + .dpms = drm_atomic_helper_connector_dpms,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .detect = ps8640_detect,
>> + .reset = drm_atomic_helper_connector_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +int ps8640_bridge_attach(struct drm_bridge *bridge)
>> +{
>> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> + struct device *dev = &ps_bridge->page[0]->dev;
>> + struct device_node *port, *in_ep;
>> + struct device_node *dsi_node = NULL;
>> + struct mipi_dsi_host *host = NULL;
>> + int ret;
>> +
>> + ret = drm_connector_init(bridge->dev, &ps_bridge->connector,
>> + &ps8640_connector_funcs,
>> + DRM_MODE_CONNECTOR_eDP);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to initialize connector with drm: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + drm_connector_helper_add(&ps_bridge->connector,
>> + &ps8640_connector_helper_funcs);
>> +
>> + ps_bridge->connector.dpms = DRM_MODE_DPMS_ON;
>> + drm_mode_connector_attach_encoder(&ps_bridge->connector,
>> + bridge->encoder);
>> +
>> + if (ps_bridge->panel)
>> + drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
>> +
>> + /* port at 0 is ps8640 dsi input port */
>> + port = of_graph_get_port_by_id(dev->of_node, 0);
>> + if (port) {
>> + in_ep = of_get_child_by_name(port, "endpoint");
>> + of_node_put(port);
The above 2 funcs can be done by a single func: of_graph_get_endpoint_by_regs().
>> + if (in_ep) {
>> + dsi_node = of_graph_get_remote_port_parent(in_ep);
>> + of_node_put(in_ep);
>> + }
>> + }
>> + if (dsi_node) {
>> + host = of_find_mipi_dsi_host_by_node(dsi_node);
>> + of_node_put(dsi_node);
>> + if (!host) {
>> + ret = -ENODEV;
>> + goto err;
>> + }
>> + }
>> +
We haven't created a DSI device for this yet. Don't we need to call
mipi_dsi_device_register_full() here?
>> + ps_bridge->dsi.host = host;
The code above proceeds even if we don't find a dsi host. In that
case, the host would be a NULL pointer. We shouldn't call
mipi_dsi_attach() with a NULL host. We should have returned earlier with
an error.
>> + ps_bridge->dsi.mode_flags = MIPI_DSI_MODE_VIDEO |
>> + MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
>> + ps_bridge->dsi.format = MIPI_DSI_FMT_RGB888;
>> + ps_bridge->dsi.lanes = 4;
>> + ret = mipi_dsi_attach(&ps_bridge->dsi);
>> + if (ret)
>> + goto err;
>> +
>> + return 0;
>> +err:
>> + if (ps_bridge->panel)
>> + drm_panel_detach(ps_bridge->panel);
>> + drm_connector_cleanup(&ps_bridge->connector);
>> + return ret;
>> +}
>> +
>> +static const struct drm_bridge_funcs ps8640_bridge_funcs = {
>> + .attach = ps8640_bridge_attach,
>> + .disable = ps8640_disable,
>> + .post_disable = ps8640_post_disable,
>> + .pre_enable = ps8640_pre_enable,
>> + .enable = ps8640_enable,
>> +};
>> +
>> +/* Firmware Version is returned as Major.Minor */
>> +static ssize_t ps8640_fw_version_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct ps8640 *ps_bridge = dev_get_drvdata(dev);
>> + struct ps8640_info *info = &ps_bridge->info;
>> +
>> + return scnprintf(buf, PAGE_SIZE, "%u.%u\n", info->version >> 8,
>> + info->version & 0xff);
>> +}
>> +
>> +/* Hardware Version is returned as FamilyID.VariantID */
>> +static ssize_t ps8640_hw_version_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct ps8640 *ps_bridge = dev_get_drvdata(dev);
>> + struct ps8640_info *info = &ps_bridge->info;
>> +
>> + return scnprintf(buf, PAGE_SIZE, "ps%u.%u\n", info->family_id,
>> + info->variant_id);
>> +}
>> +
>> +static int ps8640_spi_send_cmd(struct ps8640 *ps_bridge, u8 *cmd, u8 cmd_len)
>> +{
>> + struct i2c_client *client = ps_bridge->page[2];
>> + u8 i, buf[3] = { PAGE2_SWSPI_LEN, cmd_len - 1, TRIGGER_NO_READBACK };
>> + int ret;
>> +
>> + ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
>> + if (ret)
>> + goto err;
>> +
>> + /* write command in write port */
>> + for (i = 0; i < cmd_len; i++) {
>> + ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA, cmd[i]);
>> + if (ret)
>> + goto err_irom_disable;
>> + }
>> +
>> + ret = ps8640_write_bytes(client, buf, sizeof(buf));
>> + if (ret)
>> + goto err_irom_disable;
>> +
>> + ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
>> + if (ret)
>> + goto err;
>> +
>> + return 0;
>> +err_irom_disable:
>> + ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
>> +err:
>> + dev_err(&client->dev, "send command err: %d\n", ret);
>> + return ret;
>> +}
>> +
>> +static int ps8640_wait_spi_ready(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[2];
>> + u8 spi_rdy_st;
>> + ktime_t timeout;
>> +
>> + timeout = ktime_add_ms(ktime_get(), 200);
>> + for (;;) {
>> + ps8640_read(client, PAGE2_SPI_STATUS, &spi_rdy_st, 1);
>> + if ((spi_rdy_st & SPI_READY) != SPI_READY)
>> + break;
>> +
>> + if (ktime_compare(ktime_get(), timeout) > 0) {
>> + dev_err(&client->dev, "wait spi ready timeout\n");
>> + return -EBUSY;
>> + }
>> +
>> + msleep(20);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int ps8640_wait_spi_nobusy(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[2];
>> + u8 spi_status, buf[3] = { PAGE2_SWSPI_LEN, 0, TRIGGER_READBACK };
>> + int ret;
>> + ktime_t timeout;
>> +
>> + timeout = ktime_add_ms(ktime_get(), 500);
>> + for (;;) {
>> + /* 0x05 RDSR; Read-Status-Register */
>> + ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA,
>> + READ_STATUS_REG_CMD);
>> + if (ret)
>> + goto err_send_cmd_exit;
>> +
>> + ret = ps8640_write_bytes(client, buf, 3);
>> + if (ret)
>> + goto err_send_cmd_exit;
>> +
>> + /* delay for cmd send */
>> + usleep_range(300, 500);
>> + /* wait for SPI ROM until not busy */
>> + ret = ps8640_read(client, PAGE2_SWSPI_RDATA, &spi_status, 1);
>> + if (ret)
>> + goto err_send_cmd_exit;
>> +
>> + if (!(spi_status & BUSY))
>> + break;
>> +
>> + if (ktime_compare(ktime_get(), timeout) > 0) {
>> + dev_err(&client->dev, "wait spi no busy timeout: %d\n",
>> + ret);
>> + return -EBUSY;
>> + }
>> + }
>> +
>> + return 0;
>> +
>> +err_send_cmd_exit:
>> + dev_err(&client->dev, "send command err: %d\n", ret);
>> + return ret;
>> +}
>> +
>> +static int ps8640_wait_rom_idle(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[0];
>> + int ret;
>> +
>> + ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
>> + if (ret)
>> + goto exit;
>> +
>> + ret = ps8640_wait_spi_ready(ps_bridge);
>> + if (ret)
>> + goto err_spi;
>> +
>> + ret = ps8640_wait_spi_nobusy(ps_bridge);
>> + if (ret)
>> + goto err_spi;
>> +
>> + ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
>> + if (ret)
>> + goto exit;
>> +
>> + return 0;
>> +
>> +err_spi:
>> + ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
>> +exit:
>> + dev_err(&client->dev, "wait ps8640 rom idle fail: %d\n", ret);
>> +
>> + return ret;
>> +}
>> +
>> +static int ps8640_spi_dl_mode(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[2];
>> + int ret;
>> +
>> + /* switch ps8640 mode to spi dl mode */
>> + if (ps_bridge->gpio_mode_sel)
>> + gpiod_set_value(ps_bridge->gpio_mode_sel, 0);
>> +
>> + /* reset spi interface */
>> + ret = ps8640_write_byte(client, PAGE2_SW_RESET,
>> + SPI_SW_RESET | MPU_SW_RESET);
>> + if (ret)
>> + goto exit;
>> +
>> + ret = ps8640_write_byte(client, PAGE2_SW_RESET, MPU_SW_RESET);
>> + if (ret)
>> + goto exit;
>> +
>> + return 0;
>> +
>> +exit:
>> + dev_err(&client->dev, "fail reset spi interface: %d\n", ret);
>> +
>> + return ret;
>> +}
>> +
>> +static int ps8640_rom_prepare(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[2];
>> + struct device *dev = &client->dev;
>> + u8 i, cmd[2];
>> + int ret;
>> +
>> + cmd[0] = WRITE_ENABLE_CMD;
>> + ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
>> + if (ret) {
>> + dev_err(dev, "failed enable-write-status-register: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + cmd[0] = WRITE_STATUS_REG_CMD;
>> + cmd[1] = CLEAR_ALL_PROTECT;
>> + ret = ps8640_spi_send_cmd(ps_bridge, cmd, 2);
>> + if (ret) {
>> + dev_err(dev, "fail disable all protection: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* wait for SPI module ready */
>> + ret = ps8640_wait_rom_idle(ps_bridge);
>> + if (ret) {
>> + dev_err(dev, "fail wait rom idle: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
>> + for (i = 0; i < ARRAY_SIZE(enc_ctrl_code); i++)
>> + ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, enc_ctrl_code[i]);
>> + ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
>> +
>> + /* Enable-Write-Status-Register */
>> + cmd[0] = WRITE_ENABLE_CMD;
>> + ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
>> + if (ret) {
>> + dev_err(dev, "fail enable-write-status-register: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* chip erase command */
>> + cmd[0] = CHIP_ERASE_CMD;
>> + ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
>> + if (ret) {
>> + dev_err(dev, "fail disable all protection: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = ps8640_wait_rom_idle(ps_bridge);
>> + if (ret) {
>> + dev_err(dev, "fail wait rom idle: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int ps8640_check_chip_id(struct ps8640 *ps_bridge)
>> +{
>> + struct i2c_client *client = ps_bridge->page[4];
>> + u8 buf[4];
>> +
>> + ps8640_read(client, PAGE4_REV_L, buf, 4);
>> + return memcmp(buf, hw_chip_id, sizeof(buf));
>> +}
>> +
>> +static int ps8640_validate_firmware(struct ps8640 *ps_bridge,
>> + const struct firmware *fw)
>> +{
>> + struct i2c_client *client = ps_bridge->page[0];
>> + u16 fw_chip_id;
>> +
>> + /*
>> + * Get the chip_id from the firmware. Make sure that it is the
>> + * right controller to do the firmware and config update.
>> + */
>> + fw_chip_id = get_unaligned_le16(fw->data + FW_CHIP_ID_OFFSET);
>> +
>> + if (fw_chip_id != 0x8640 && ps8640_check_chip_id(ps_bridge) == 0) {
>> + dev_err(&client->dev,
>> + "chip id mismatch: fw 0x%x vs. chip 0x8640\n",
>> + fw_chip_id);
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int ps8640_write_rom(struct ps8640 *ps_bridge, const struct firmware *fw)
>> +{
>> + struct i2c_client *client = ps_bridge->page[0];
>> + struct device *dev = &client->dev;
>> + struct i2c_client *client2 = ps_bridge->page[2];
>> + struct i2c_client *client7 = ps_bridge->page[7];
>> + size_t pos, cpy_len;
>> + u8 buf[257];
>> + int ret;
>> +
>> + ps8640_write_byte(client2, PAGE2_SPI_CFG3, I2C_TO_SPI_RESET);
>> + msleep(100);
>> + ps8640_write_byte(client2, PAGE2_SPI_CFG3, 0x00);
>> +
>> + for (pos = 0; pos < fw->size; pos += cpy_len) {
>> + buf[0] = PAGE2_ROMADD_BYTE1;
>> + buf[1] = pos >> 8;
>> + buf[2] = pos >> 16;
>> + ret = ps8640_write_bytes(client2, buf, 3);
>> + if (ret)
>> + goto error;
>> + cpy_len = fw->size >= 256 + pos ? 256 : fw->size - pos;
>> + buf[0] = 0;
>> + memcpy(buf + 1, fw->data + pos, cpy_len);
>> + ret = ps8640_write_bytes(client7, buf, cpy_len + 1);
>> + if (ret)
>> + goto error;
>> +
>> + dev_dbg(dev, "fw update completed %zu / %zu bytes\n", pos,
>> + fw->size);
>> + }
>> + return 0;
>> +
>> +error:
>> + dev_err(dev, "failed write external flash, %d\n", ret);
>> + return ret;
>> +}
>> +
>> +static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
>> +{
>> + u8 cmd[2];
>> + struct i2c_client *client = ps_bridge->page[2];
>> +
>> + /* Enable-Write-Status-Register */
>> + cmd[0] = WRITE_ENABLE_CMD;
>> + ps8640_spi_send_cmd(ps_bridge, cmd, 1);
>> +
>> + /* protect BPL/BP0/BP1 */
>> + cmd[0] = WRITE_STATUS_REG_CMD;
>> + cmd[1] = BLK_PROTECT_BITS | STATUS_REG_PROTECT;
>> + ps8640_spi_send_cmd(ps_bridge, cmd, 2);
>> +
>> + /* wait for SPI rom ready */
>> + ps8640_wait_rom_idle(ps_bridge);
>> +
>> + /* disable PS8640 mapping function */
>> + ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
>> +
>> + if (ps_bridge->gpio_mode_sel)
>> + gpiod_set_value(ps_bridge->gpio_mode_sel, 1);
>> + return 0;
>> +}
>> +
>> +static int ps8640_enter_bl(struct ps8640 *ps_bridge)
>> +{
>> + ps_bridge->in_fw_update = true;
>> + return ps8640_spi_dl_mode(ps_bridge);
>> +}
>> +
>> +static void ps8640_exit_bl(struct ps8640 *ps_bridge, const struct firmware *fw)
>> +{
>> + ps8640_spi_normal_mode(ps_bridge);
>> + ps_bridge->in_fw_update = false;
>> +}
>> +
>> +static int ps8640_load_fw(struct ps8640 *ps_bridge, const struct firmware *fw)
>> +{
>> + struct i2c_client *client = ps_bridge->page[0];
>> + struct device *dev = &client->dev;
>> + int ret;
>> + bool ps8640_status_backup = ps_bridge->enabled;
>> +
>> + ret = ps8640_validate_firmware(ps_bridge, fw);
>> + if (ret)
>> + return ret;
>> +
>> + mutex_lock(&ps_bridge->fw_mutex);
>> + if (!ps_bridge->in_fw_update) {
>> + if (!ps8640_status_backup)
>> + ps8640_pre_enable(&ps_bridge->bridge);
>> +
>> + ret = ps8640_enter_bl(ps_bridge);
>> + if (ret)
>> + goto exit;
>> + }
>> +
>> + ret = ps8640_rom_prepare(ps_bridge);
>> + if (ret)
>> + goto exit;
>> +
>> + ret = ps8640_write_rom(ps_bridge, fw);
>> +
>> +exit:
>> + if (ret)
>> + dev_err(dev, "Failed to load firmware, %d\n", ret);
>> +
>> + ps8640_exit_bl(ps_bridge, fw);
>> + if (!ps8640_status_backup)
>> + ps8640_post_disable(&ps_bridge->bridge);
>> + mutex_unlock(&ps_bridge->fw_mutex);
>> + return ret;
>> +}
>> +
>> +static ssize_t ps8640_update_fw_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> + struct ps8640 *ps_bridge = i2c_get_clientdata(client);
>> + const struct firmware *fw;
>> + int error;
>> +
>> + error = request_firmware(&fw, PS_FW_NAME, dev);
>> + if (error) {
>> + dev_err(dev, "Unable to open firmware %s: %d\n",
>> + PS_FW_NAME, error);
>> + return error;
>> + }
>> +
>> + error = ps8640_load_fw(ps_bridge, fw);
>> + if (error)
>> + dev_err(dev, "The firmware update failed(%d)\n", error);
>> + else
>> + dev_info(dev, "The firmware update succeeded\n");
>> +
>> + release_firmware(fw);
>> + return error ? error : count;
>> +}
>> +
>> +static DEVICE_ATTR(fw_version, S_IRUGO, ps8640_fw_version_show, NULL);
>> +static DEVICE_ATTR(hw_version, S_IRUGO, ps8640_hw_version_show, NULL);
>> +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, ps8640_update_fw_store);
>> +
>> +static struct attribute *ps8640_attrs[] = {
>> + &dev_attr_fw_version.attr,
>> + &dev_attr_hw_version.attr,
>> + &dev_attr_update_fw.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group ps8640_attr_group = {
>> + .attrs = ps8640_attrs,
>> +};
>> +
>> +static void ps8640_remove_sysfs_group(void *data)
>> +{
>> + struct ps8640 *ps_bridge = data;
>> +
>> + sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
>> +}
>> +
>> +static int ps8640_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct device *dev = &client->dev;
>> + struct ps8640 *ps_bridge;
>> + struct device_node *np = dev->of_node;
>> + struct device_node *port, *out_ep;
>> + struct device_node *panel_node = NULL;
>> + int ret;
>> + u32 i;
>> +
>> + ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
>> + if (!ps_bridge)
>> + return -ENOMEM;
>> +
>> + /* port at 1 is ps8640 output port */
>> + port = of_graph_get_port_by_id(np, 1);
>> + if (port) {
>> + out_ep = of_get_child_by_name(port, "endpoint");
>> + of_node_put(port);
>> + if (out_ep) {
>> + panel_node = of_graph_get_remote_port_parent(out_ep);
>> + of_node_put(out_ep);
>> + }
>> + }
>> + if (panel_node) {
>> + ps_bridge->panel = of_drm_find_panel(panel_node);
>> + of_node_put(panel_node);
>> + if (!ps_bridge->panel)
>> + return -EPROBE_DEFER;
>> + }
>> +
>> + mutex_init(&ps_bridge->fw_mutex);
>> + ps_bridge->supplies[0].supply = "vdd33";
>> + ps_bridge->supplies[1].supply = "vdd12";
>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ps_bridge->supplies),
>> + ps_bridge->supplies);
>> + if (ret) {
>> + dev_info(dev, "failed to get regulators: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ps_bridge->gpio_mode_sel = devm_gpiod_get_optional(&client->dev,
>> + "mode-sel",
>> + GPIOD_OUT_HIGH);
>> + if (IS_ERR(ps_bridge->gpio_mode_sel)) {
>> + ret = PTR_ERR(ps_bridge->gpio_mode_sel);
>> + dev_err(dev, "cannot get mode-sel %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ps_bridge->gpio_power_down = devm_gpiod_get(&client->dev, "sleep",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(ps_bridge->gpio_power_down)) {
>> + ret = PTR_ERR(ps_bridge->gpio_power_down);
>> + dev_err(dev, "cannot get sleep: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /*
>> + * Request the reset pin low to avoid the bridge being
>> + * initialized prematurely
>> + */
>> + ps_bridge->gpio_reset = devm_gpiod_get(&client->dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(ps_bridge->gpio_reset)) {
>> + ret = PTR_ERR(ps_bridge->gpio_reset);
>> + dev_err(dev, "cannot get reset: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
>> + ps_bridge->bridge.of_node = dev->of_node;
>> +
>> + ps_bridge->page[0] = client;
>> + ps_bridge->ddc_i2c = i2c_new_dummy(client->adapter, EDID_I2C_ADDR);
I don't see why we need to create this dummy client. The drm edid helper
drm_get_edid() just needs the i2c adapter to which the client is connected.
It will internally initiate a read form the address EDID_I2C_ADDR.
I guess "drm_get_edid(connector, ps_bridge->page[0]->adapter)" should work.
>> + if (!ps_bridge->ddc_i2c) {
>> + dev_err(dev, "failed ddc_i2c dummy device, address%02x\n",
>> + EDID_I2C_ADDR);
>> + return -EBUSY;
>> + }
>> + /*
>> + * ps8640 uses multiple addresses, use dummy devices for them
>> + * page[0]: for DP control
>> + * page[1]: for VIDEO Bridge
>> + * page[2]: for control top
>> + * page[3]: for DSI Link Control1
>> + * page[4]: for MIPI Phy
>> + * page[5]: for VPLL
>> + * page[6]: for DSI Link Control2
Does this chip support 2 DSI inputs, and we're just exposing one for now?
If so, we should probably revisit the DT bindings, so that port at 2 doesn't
need to represent the 2nd DSI link.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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