* Re: [PATCH 2/2] Documentation: DT: Add bmi160 imu binding
From: Rob Herring @ 2016-11-10 18:55 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Daniel Baluta, Gregor Boirie,
Sanchayan Maity, Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161103112527.29623-2-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
On Thu, Nov 03, 2016 at 12:25:27PM +0100, Marcin Niestroj wrote:
> This adds documentation for Bosch BMI160 Inertial Measurement Unit
> device-tree bindings.
>
> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
> ---
> .../devicetree/bindings/iio/imu/bmi160.txt | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/bmi160.txt b/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> new file mode 100644
> index 0000000..b02ef3e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> @@ -0,0 +1,34 @@
> +Bosch BMI160 - Inertial Measurement Unit with Accelerometer, Gyroscope
> +and externally connectable Magnetometer
> +
> +https://www.bosch-sensortec.com/bst/products/all_products/bmi160
> +
> +Required properties:
> + - compatible : should be "bosch,bmi160"
> + - reg : the I2C address or SPI chip select number of the sensor
> + - spi-max-frequency : set maximum clock frequency (only for SPI)
> +
> +Optional properties:
> + - interrupt-parent : should be the phandle of the interrupt controller
> + - interrupts : interrupt mapping for GPIO IRQ, must be IRQ_TYPE_LEVEL_LOW
The fact that a GPIO is typically used is outside the scope of this doc.
> + - interrupt-names : set to "INT2" if using INT2 pin
Normally there's no point to have names property when there is a single
interrupt. However, it seems this could be either INT1 or INT2 or both
connected. You need to specify all the options.
Rob
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Rob Herring @ 2016-11-10 18:56 UTC (permalink / raw)
To: Andy Yan
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8
In-Reply-To: <1478176250-11840-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Nov 03, 2016 at 08:30:50PM +0800, Andy Yan wrote:
> From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
> dwmmc on rk1108 platform.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Rob Herring @ 2016-11-10 18:57 UTC (permalink / raw)
To: Andy Yan
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478177039-12257-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Nov 03, 2016 at 08:43:59PM +0800, Andy Yan wrote:
> RK1108EVB is designed by Rockchip for CVR field.
> This patch add basic support for it, which can boot with
> initramfs into shell.
>
> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
> 3 files changed, 73 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Olof Johansson @ 2016-11-10 19:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Neil Armstrong, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-amlogic
In-Reply-To: <7ccc12bc-9a05-47e3-8ab8-d1b0ad31159e@arm.com>
On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 14:12, Rob Herring wrote:
>>
>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>
>>>
>>>
>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>> operations.
>>>>>
>>>>> Required properties:
>>>>>
>>>>> -- compatible : should be "arm,scpi"
>>>>> +- compatible : should be
>>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>> above
>>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>> v1.0
>>>>
>>>>
>>>>
>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>> many?
>>>>
>>>
>>> I understand your concern, but this legacy SCPI protocol was not
>>> officially released. It was just WIP which vendors picked up from very
>>> early releases. Since they are not numbered, it's hard to have specific
>>> compatibles with different versions until v1.0. That's one of the reason
>>> to retain platform specific compatible so that we can add any quirks
>>> based on them if needed.
>>>
>>> I will probably add these information in the commit log so that it's
>>> clear why we can't do version based compatible.
>>
>>
>> This is exactly my point. By enumerate, I meant having platform
>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>> who knows what version they followed and they may all be different.
>>
>
> OK, but IIUC Olof's concern wanted a generic one along with the platform
> specific compatible which kind of makes sense as so far we have seen
> some commonality between Amlogic and Rockchip.
>
> E.g. Amlogic follows most of the legacy protocol though it deviates in
> couple of things which we can handle with platform specific compatible
> (in the following patch in the series). When another user(Rockchip ?)
> make use of this legacy protocol, we can start using those platform
> specific compatible for deviations only.
>
> Is that not acceptable ?
If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.
What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.
I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.
-Olof
^ permalink raw reply
* Re: [RESEND PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters
From: Mark Rutland @ 2016-11-10 19:10 UTC (permalink / raw)
To: Anurup M
Cc: devicetree, linux-arm-kernel, linux-doc, will.deacon, corbet,
catalin.marinas, robh+dt, arnd, f.fainelli, rmk+kernel, krzk,
anurup.m, zhangshaokun, tanxiaojun, xuwei5, sanil.kumar,
john.garry, gabriele.paoloni, shiju.jose, wangkefeng.wang,
guohanjun, shyju.pv, linuxarm
In-Reply-To: <1478151727-20250-8-git-send-email-anurup.m@huawei.com>
On Thu, Nov 03, 2016 at 01:42:03AM -0400, Anurup M wrote:
> + do {
> + /* Get count from individual L3C banks and sum them up */
> + for (i = 0; i < num_banks; i++) {
> + total_raw_count += hisi_read_l3c_counter(l3c_hwmod_data,
> + idx, i);
> + }
> + prev_raw_count = local64_read(&hwc->prev_count);
> +
> + /*
> + * As prev_raw_count is updated with average value of
> + * L3 cache banks, we multiply it by no of banks and
> + * compute the delta
> + */
> + delta = (total_raw_count - (prev_raw_count * num_banks)) &
> + HISI_MAX_PERIOD;
> +
> + local64_add(delta, &event->count);
> +
> + /*
> + * Divide by num of banks to get average count and
> + * update prev_count with this value
> + */
> + avg_raw_count = total_raw_count / num_banks;
> + } while (local64_cmpxchg(
> + &hwc->prev_count, prev_raw_count, avg_raw_count) !=
> + prev_raw_count);
Please don't aggregate like this; expose separate PMUs instead.
This is racy, and by averaging and multiplying we're making up and/or
throwing away data.
[...]
> + event_value = (val -
> + HISI_HWEVENT_L3C_READ_ALLOCATE);
> +
> + /* Select the appropriate Event select register */
> + if (idx > 3)
> + reg_offset += 4;
> +
> + /* Value to write to event type register */
> + val = event_value << (8 * idx);
> +
Please add helpers for these, and explain *why* the transformations are
necessary.
> + /* Find the djtag Identifier of the Unit */
> + client = l3c_hwmod_data->client;
> +
> + /*
> + * Set the event in L3C_EVENT_TYPEx Register
> + * for all L3C banks
> + */
As above, it seems like you should expose a separate PMU per bank
instead. That applies for all the other instances where you iterate over
banks.
[...]
> + for (i = 0; i < l3c_hwmod_data->l3c_hwcfg.num_banks; i++) {
> + module_id = l3c_hwmod_data->l3c_hwcfg.module_id[i];
> + cfg_en = l3c_hwmod_data->l3c_hwcfg.bank_cfgen[i];
> + ret = hisi_djtag_writereg(module_id,
> + cfg_en,
> + reg_offset,
> + value,
> + client);
> + if (!ret)
> + ret = value;
> + }
This is impossible to read. Please factor this into helpers such that
you don't need this amount of indentation.
Please do similarly elsewhere when you see this indentation pattern.
[...]
> +static int hisi_l3c_get_event_idx(struct hisi_pmu *pl3c_pmu)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = pl3c_pmu->hwmod_data;
> + int event_idx;
> +
> + event_idx =
> + find_first_zero_bit(
> + l3c_hwmod_data->hisi_l3c_event_used_mask,
> + pl3c_pmu->num_counters);
> +
> + if (event_idx == HISI_MAX_CFG_L3C_CNTR)
> + return -EAGAIN;
> +
> + __set_bit(event_idx,
> + l3c_hwmod_data->hisi_l3c_event_used_mask);
> +
> + return event_idx;
> +}
Please get rid of the weird hungarian notation (i.e. don't use 'p' as a
prefix for pointers), and use temporary variables consistently, e.g.
static int hisi_l3c_get_event_idx(struct hisi_pmu *l3c_pmu)
{
struct hisi_l3c_data *l3c_hwmod_data = l3c_pmu->hwmod_data;
unsigned long *used_mask = l3c_hwmod_data->hisi_l3c_event_used_mask;
int num_counters = pl3c_pmu->num_counters
int idx;
idx = find_first_zero_bit(used_mask, num_counters);
if (idx == num_counters)
return -EAGAIN;
set_bit(idx, used_mask);
return idx;
}
[...]
> + if (of_property_read_u32(node, "counter-reg",
> + &pl3c_hwcfg->counter_reg0_off)) {
> + dev_err(dev, "DT:Couldnot read counter-reg!\n");
> + return -EINVAL;
> + }
Please use spaces in these messages.
Otherwise, my comments on the binding apply here.
[...]
> +static int init_hisi_l3c_data(struct device *dev,
> + struct hisi_pmu *pl3c_pmu,
> + struct hisi_djtag_client *client)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = NULL;
> + int ret;
> +
> + l3c_hwmod_data = kzalloc(sizeof(struct hisi_l3c_data),
> + GFP_KERNEL);
Use:
l3c_hwmod_data = kzalloc(sizeof(*l3c_hwmod_data, GFP_KERNEL):
[...]
> +static int hisi_pmu_l3c_dev_probe(struct hisi_djtag_client *client)
> +{
> + struct hisi_pmu *pl3c_pmu = NULL;
> + struct device *dev = &client->dev;
> + int ret;
> +
> + pl3c_pmu = hisi_pmu_alloc(dev);
> + if (IS_ERR(pl3c_pmu))
> + return PTR_ERR(pl3c_pmu);
Why use error pointers for this?
hisi_pmu_alloc() only ever returns ERR_PTR(-ENOMEM) if it failed to
allocate.
It's far simpler to have it pass on NULL there, and here do:
pl3c_pmu = hisi_pmu_alloc(dev);
if (!pl3c_pmu)
return -ENOMEM;
Please also s/pl3c_pmu/l3c_pmu/ here, and elsewhere throughout the
driver. The 'p' only serves to make this harder to read.
[...]
> + /* Register with perf PMU */
> + pl3c_pmu->pmu = (struct pmu) {
> + .name = pl3c_pmu->name,
> + .task_ctx_nr = perf_invalid_context,
> + .event_init = hisi_uncore_pmu_event_init,
> + .add = hisi_uncore_pmu_add,
> + .del = hisi_uncore_pmu_del,
> + .start = hisi_uncore_pmu_start,
> + .stop = hisi_uncore_pmu_stop,
> + .read = hisi_uncore_pmu_read,
> + };
Please remove the comment above this.
[...]
> +int hisi_uncore_pmu_event_init(struct perf_event *event)
> +{
> + int err;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
This is undefined behaviour. This must be done *after* we check the
event->pmu->type.
> +
> + if (event->attr.type != event->pmu->type)
> + return -ENOENT;
> +
> + /* we do not support sampling as the counters are all
> + * shared by all CPU cores in a CPU die(SCCL). Also we
> + * donot support attach to a task(per-process mode)
> + */
> + if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> + return -EOPNOTSUPP;
> +
> + /* counters do not have these bits */
> + if (event->attr.exclude_user ||
> + event->attr.exclude_kernel ||
> + event->attr.exclude_host ||
> + event->attr.exclude_guest ||
> + event->attr.exclude_hv ||
> + event->attr.exclude_idle)
> + return -EINVAL;
> +
> + if (event->cpu < 0)
> + return -EINVAL;
> +
> + event->cpu = cpumask_first(&phisi_pmu->cpu);
You should also check the event grouping.
Take a look at what we do in arch/arm/mm/cache-l2x0-pmu.c.
[...]
> +/*
> + * Enable counter and set the counter to count
> + * the event that we're interested in.
> + */
> +void hisi_uncore_pmu_enable_event(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + /* Disable the hardware event counting */
> + if (phisi_pmu->ops->disable_counter)
> + phisi_pmu->ops->disable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
Why isn't the counter already disabled?
> + /*
> + * Set event (if destined for Hisilicon SoC counters).
> + */
> + if (phisi_pmu->ops->set_evtype)
> + phisi_pmu->ops->set_evtype(phisi_pmu, GET_CNTR_IDX(hwc),
> + hwc->config_base);
Why isn't this done in the pmu::event_add callback?
> +
> + /* Enable the hardware event counting */
> + if (phisi_pmu->ops->enable_counter)
> + phisi_pmu->ops->enable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
This should be the only necessary part of this function.
> +}
> +
> +void hisi_pmu_set_event_period(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + /*
> + * The Hisilicon PMU counters have a period of 2^32. To account for the
> + * possiblity of extreme interrupt latency we program for a period of
> + * half that. Hopefully we can handle the interrupt before another 2^31
> + * events occur and the counter overtakes its previous value.
> + */
> + u64 val = 1ULL << 31;
> +
> + local64_set(&hwc->prev_count, val);
> +
> + /* Write to the hardware event counter */
> + phisi_pmu->ops->write_counter(phisi_pmu, hwc, val);
> +}
> +
> +void hisi_uncore_pmu_start(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> + struct hisi_pmu_hw_events *hw_events;
> +
> + hw_events = &phisi_pmu->hw_events;
> +
> + if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
> + return;
> +
> + WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
> + hwc->state = 0;
> +
> + if (phisi_pmu->ops->set_event_period)
> + phisi_pmu->ops->set_event_period(event);
When will this differ from hisi_pmu_set_event_period() above?
> + if (flags & PERF_EF_RELOAD) {
> + u64 prev_raw_count = local64_read(&hwc->prev_count);
> +
> + phisi_pmu->ops->write_counter(phisi_pmu, hwc,
> + (u32)prev_raw_count);
> + }
If we always go through hisi_pmu_set_event_period(), this looks
redundant.
> +
> + hisi_uncore_pmu_enable_event(event);
There's no matching disable_event() call in this function, so this looks
suspicious.
> + perf_event_update_userpage(event);
> +}
> +
> +void hisi_uncore_pmu_stop(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + if (hwc->state & PERF_HES_UPTODATE)
> + return;
Why?
[...]
> +int hisi_uncore_common_fwprop_read(struct device *dev,
> + struct hisi_pmu *phisi_pmu)
> +{
> + if (device_property_read_u32(dev, "num-events",
> + &phisi_pmu->num_events)) {
> + dev_err(dev, "Cant read num-events from DT!\n");
> + return -EINVAL;
> + }
For consistency with the rest of the driver, and given there is no ACPI
support, please use the of_property_* API here.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices
From: Rob Herring @ 2016-11-10 19:25 UTC (permalink / raw)
To: Olimpiu Dejeu; +Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jg1.han
In-Reply-To: <1478197768-3694-1-git-send-email-olimpiu@arcticsand.com>
On Thu, Nov 03, 2016 at 02:29:28PM -0400, Olimpiu Dejeu wrote:
> Resubmition of arcxcnn backliught driver addressing the naming convention
s/Resubmition/Re-submission/
s/backliught/backlight/
> concerns raised by Rob H. Note that all the device tree properties are
> determined by the board design or IC EPROM settings and are not intended
> to be user adjustable.
>
> Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
>
> ---
> .../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Benjamin Herrenschmidt @ 2016-11-10 19:32 UTC (permalink / raw)
To: Mark Rutland
Cc: zhichang.yuan, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
liviu.dudau-5wv7dgnIgG8, zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <20161110112224.GB4418@leverpostej>
On Thu, 2016-11-10 at 11:22 +0000, Mark Rutland wrote:
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> > firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
> Just to check, do you hook that in your inb/outb/etc?
Yes.
> Generally, it would seem nicer if we could have higher-level
> isa_{inb,outb,whatever} accessors that we could hook separately from
> other IO.
Maybe but generally speaking, we don't discriminate accessors per bus,
ie, readl etc... work on all memory mapped busses, inb... works on all
busses with an "IO space", at least that's been the idea. It probably
all comes from the fact that PCI IO and ISA are the same space on
x86 and most other platforms (not all).
> We don't necessarily have to move all ISA drivers over to that if we had
> a separate symbol for that interface.
What I do on ppc today is that I have a chunk of virtual address space
that is reserved for "IO space". The first 64k are "reserved" in that
they route to "the primary" ISA bus (for legacy crap that uses hard
coded addresses, though I use that for my LPC bus too). I "allocate"
space for the PCI IO spaces higher in that space. Was I to support more
LPC busses I could allocate them up there too.
The IO resource of a given device thus becomes the actual IO port plus
the offset of the base of the segment it's in.
For memory mapped IO, inb/outb will just add the virtual address of
the base of all IO space to that. The hooking mechanism will pickup
the stuff that isn't memory mapped.
It's a bit messy but then IO space performance has never been a huge
worry since IO cycles tend to be very slow to begin with.
Note: We also have the ISA memory and ISA FW spaces that we don't have
good accessors for. They somewhat exist (I think the fbdev layer uses
some for vga) but it's messy.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-10 19:56 UTC (permalink / raw)
To: Rob Herring, Kevin Hilman, Ulf Hansson, Jon Hunter
Cc: Nishanth Menon, devicetree@vger.kernel.org,
linux-pm@vger.kernel.org, Keerthy, Santosh Shilimkar,
Rafael J . Wysocki, linux-kernel@vger.kernel.org, Tero Kristo,
Russell King, Sudeep Holla, linux-arm-kernel@lists.infradead.org
In-Reply-To: <5811FE09.8000006@ti.com>
Rob, Ulf, Jon,
On 10/27/2016 08:15 AM, Dave Gerlach wrote:
> +Jon
> On 10/26/2016 04:59 PM, Rob Herring wrote:
>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>
>>>> Hi,
>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>> control device power states.
>>>>>>
>>>>>> Also, provide macros representing each device index as understood
>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>
>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>>>>>> MAINTAINERS | 2 +
>>>>>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>>>>>> 3 files changed, 146 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..32f38a349656
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> @@ -0,0 +1,54 @@
>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>> +---------------------------------------------
>>>>>> +
>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>> +Communication between the host processor running an OS and the system
>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>>>>> +implementation plugs into the generic pm domain framework and makes use of
>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>> +
>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>> +
>>>>>> +PM Domain Node
>>>>>> +==============
>>>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>>>> +which in this case is the single implementation as documented by the generic
>>>>>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>> +- #power-domain-cells: Must be 0.
>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>>>>>
>>>>>> +Example:
>>>>>> +--------------------
>>>>>> +k2g_pds: k2g_pds {
>>>>>
>>>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>>>
>>>> Ok, that makes more sense.
>>>>
>>>>>
>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>> + #power-domain-cells = <0>;
>>>>>> + ti,sci = <&pmmc>;
>>>>>> +};
>>>>>> +
>>>>>> +PM Domain Consumers
>>>>>> +===================
>>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>>> +specific ID that identifies the device.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>>> + be used for device control.
>>>>>
>>>>> This ID doesn't look right.
>>>>>
>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
>>
>> Exactly. ti,sci-id is a NAK for me.
>
> I was told not to use the onecell during v1 discussion. I agree this would be
> ideal but I cannot due to what the bindings represent, the phandle parameter is
> an index into a list of genpds, whereas we need an actual ID number we can use
> and I do not have the ability to get that from the phandle.
>
> @Ulf/Jon, is there any hope of bringing back custom xlate functions for genpd
> providers? I don't have a good background on why it was even removed. I can
> maintain a single genpd for all devices but I need a way to parse this ID,
> whether it's from a separate property or a phandle. It is locked now to indexing
> into a list of genpds but I need additional per device information for devices
> bound to a genpd and I need either a custom parameter or the ability to parse
> the phandle myself.
>
Any comments here? The meaning of the phandle onecell is fixed in the
genpd framework so I'm not sure how we want to move forward with this, I
need to pass a power domain ID to the genpd driver, and if this
shouldn't be a new property I'm not sure what direction we should take.
Regards,
Dave
>>
>>>>>
>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------------------
>>>>>> +uart0: serial@02530c00 {
>>>>>> + compatible = "ns16550a";
>>>>>> + ...
>>>>>> + power-domains = <&k2g_pds>;
>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>
>>>>> ... like this:
>>>>>
>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>
>>>> That's how I did it in version one actually. I was able to define my
>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>> providers and dropped the concept of adding your own xlate. This locks
>>>> the onecell approach to using a fixed static array of genpds that get
>>>> indexed into (without passing the index to the provider, just the
>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>
>> I have no idea what any of this means. All sounds like driver
>> architecture, not anything to do with bindings.
>
> This was a response to Kevin, not part of binding description.
>
>>
>>>
>>> Ah, right. I remember now. This approach allows you to use a single
>>> genpd as discussed earlier.
>>>
>>> Makes sense now, suggestion retracted.
>>
>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>> need any additional property.
>
> Yes but we only have one domain and index into it, not into a list of domains,
> so the additional property is solving a different problem.
>
> Regards,
> Dave
>
>>
>> Rob
>>
>
^ permalink raw reply
* Re: [PATCH] PM / Domains: Fix compatible for domain idle state
From: Rob Herring @ 2016-11-10 19:58 UTC (permalink / raw)
To: Ulf Hansson
Cc: Lina Iyer, Kevin Hilman, Rafael J. Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Andy Gross, Stephen Boyd,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Brendan Jackman, Lorenzo Pieralisi, Sudeep Holla, Juri Lelli,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAPDyKFoCjf1qSBDWUY_wNx21_78fRrFqcqrFbsSmabzAZJxQAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 07, 2016 at 12:14:28PM +0100, Ulf Hansson wrote:
> On 3 November 2016 at 22:54, Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > Re-using idle state definition provided by arm,idle-state for domain
> > idle states creates a lot of confusion and limits further evolution of
> > the domain idle definition. To keep things clear and simple, define a
> > idle states for domain using a new compatible "domain-idle-state".
> >
> > Fix existing PM domains code to look for the newly defined compatible.
> >
> > Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
> > .../devicetree/bindings/power/power_domain.txt | 8 +++---
> > drivers/base/power/domain.c | 2 +-
> > 3 files changed, 38 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
> >
> > diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > new file mode 100644
> > index 0000000..eefc7ed
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > @@ -0,0 +1,33 @@
> > +PM Domain Idle State Node:
> > +
> > +A domain idle state node represents the state parameters that will be used to
> > +select the state when there are no active components in the domain.
> > +
> > +The state node has the following parameters -
> > +
> > +- compatible:
> > + Usage: Required
> > + Value type: <string>
> > + Definition: Must be "domain-idle-state".
> > +
> > +- entry-latency-us
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: u32 value representing worst case latency in
> > + microseconds required to enter the idle state.
> > + The exit-latency-us duration may be guaranteed
> > + only after entry-latency-us has passed.
>
> As we anyway are going to change this, why not use an u64 and have the
> value in ns instead of us?
I can't imagine that you would need more resolution or range. For times
less than 1us, s/w and register access times are going to dominate the
time.
Unless there is a real need, I'd keep alignment with the existing
binding.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 11/13] Documentation: devicetree: dwc2: Add host DMA binding
From: Rob Herring @ 2016-11-10 19:59 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <6eb07c204dcbe7d3d9cb3db593828558ad6b3117.1478220875.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Thu, Nov 03, 2016 at 05:56:10PM -0700, John Youn wrote:
> Add the snps,host-dma-disable binding. This controls whether to disable
> DMA in host mode.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Rob Herring @ 2016-11-10 20:26 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, Bjorn Helgaas, linux-pci, Mark Rutland, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <1478264387-17914-3-git-send-email-srinivas.kandagatla@linaro.org>
On Fri, Nov 04, 2016 at 12:59:46PM +0000, Srinivas Kandagatla wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
> pipe clocks are only setup after the phy is powered on.
> It also adds ltssm_enable callback as it is very much different to other
> supported SOCs in the driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
> drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
> 2 files changed, 239 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> index 4059a6f..4a0538d 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -7,6 +7,7 @@
> - "qcom,pcie-ipq8064" for ipq8064
> - "qcom,pcie-apq8064" for apq8064
> - "qcom,pcie-apq8084" for apq8084
> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>
> - reg:
> Usage: required
> @@ -92,6 +93,16 @@
> - "aux" Auxiliary (AUX) clock
> - "bus_master" Master AXI clock
> - "bus_slave" Slave AXI clock
> +
> +- clock-names:
> + Usage: required for msm8996/apq8096
> + Value type: <stringlist>
> + Definition: Should contain the following entries
> + - "aux" Auxiliary (AUX) clock.
> + - "bus_master" Master AXI clock.
> + - "bus_slave" Slave AXI clock.
> + - "pipe" Pipe Clock driving internal logic.
> + - "cfg" Configuration clk.
The order here and the order in the example don't match. The order
should be defined.
> - resets:
> Usage: required
> Value type: <prop-encoded-array>
> @@ -115,7 +126,7 @@
> - "core" Core reset
>
> - power-domains:
> - Usage: required for apq8084
> + Usage: required for apq8084 and msm8996/apq8096
> Value type: <prop-encoded-array>
> Definition: A phandle and power domain specifier pair to the
> power domain which is responsible for collapsing
> @@ -231,3 +242,58 @@
> pinctrl-0 = <&pcie0_pins_default>;
> pinctrl-names = "default";
> };
> +
> +* Example for apq8096:
> +
> + pcie@00608000{
Drop leading 0s.
> + compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
> + power-domains = <&gcc PCIE1_GDSC>;
> + bus-range = <0x00 0xff>;
> + num-lanes = <1>;
> +
> + status = "disabled";
No point to have status in the example.
> +
> + reg = <0x00608000 0x2000>,
> + <0x0d000000 0xf1d>,
> + <0x0d000f20 0xa8>,
> + <0x0d100000 0x100000>;
> +
> + reg-names = "parf", "dbi", "elbi", "config";
> +
> + phys = <&pcie_phy 1>;
> + phy-names = "pciephy";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
> + <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
> +
> + interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
> + interrupt-names = "msi";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> + <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> + <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> + <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
> + pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
> +
> + vdda-1p8-supply = <&pm8994_l12>;
> + vdda-supply = <&pm8994_l28>;
> + linux,pci-domain = <1>;
> +
> + clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
> + <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
> +
> + clock-names = "pipe",
> + "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave";
> + };
^ permalink raw reply
* Re: [PATCH v2 1/3] remoteproc: qcom: Encapsulate pvt data structure for q6v56 hexagon.
From: Rob Herring @ 2016-11-10 20:30 UTC (permalink / raw)
To: Avaneesh Kumar Dwivedi
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Ohad Ben-Cohen,
Mark Rutland, open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <1478268057-11847-2-git-send-email-akdwived-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Fri, Nov 04, 2016 at 07:30:54PM +0530, Avaneesh Kumar Dwivedi wrote:
> Encapsulate resources specific to each version of hexagon chip to
> device node to avoid conditional check for manipulation of those
> resources in driver code.
>
> Signed-off-by: Avaneesh Kumar Dwivedi <akdwived-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 1 +
> drivers/remoteproc/qcom_q6v5_pil.c | 137 ++++++++++++++++++---
> 2 files changed, 120 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> index 57cb49e..cbc165c 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> @@ -8,6 +8,7 @@ on the Qualcomm Hexagon core.
> Value type: <string>
> Definition: must be one of:
> "qcom,q6v5-pil"
> + "qcom,q6v56-pil"
Perhaps some explanation in the commit message about what these magic
numbers mean?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.
From: Rob Herring @ 2016-11-10 20:51 UTC (permalink / raw)
To: David Daney
Cc: David Daney, linux-kernel@vger.kernel.org, Frank Rowand,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Will Deacon, Catalin Marinas, Robert Richter, Hanjun Guo,
Ganapatrao Kulkarni, Gilbert Netzer, David Daney
In-Reply-To: <93b7769a-4907-176e-9f18-0bf6bd72d15d@caviumnetworks.com>
On Thu, Nov 3, 2016 at 10:11 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 11/02/2016 08:37 PM, Rob Herring wrote:
>>
>> On Fri, Oct 28, 2016 at 4:15 PM, David Daney <ddaney.cavm@gmail.com>
>> wrote:
>>>
>>> From: David Daney <david.daney@cavium.com>
>>>
>>> On arm64 NUMA kernels we can pass "numa=off" on the command line to
>>> disable NUMA. A side effect of this is that kmalloc_node() calls to
>>> non-zero nodes will crash the system with an OOPS:
>>>
>>> [ 0.000000] ITS@0x0000901000020000: allocated 2097152 Devices
>>> @10002000000 (flat, esz 8, psz 64K, shr 1)
>>> [ 0.000000] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00001680
>>> [ 0.000000] pgd = fffffc0009470000
>>> [ 0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003,
>>> *pmd=0000010ffff90003, *pte=0000000000000000
>>> [ 0.000000] Internal error: Oops: 96000006 [#1] SMP
>>> .
>>> .
>>> .
>>> [ 0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
>>> [ 0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
>>> [ 0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
>>> [ 0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
>>> [ 0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
>>> [ 0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
>>> [ 0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
>>> [ 0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
>>> [ 0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
>>> [ 0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
>>> [ 0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
>>> [ 0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
>>> [ 0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
>>> [ 0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
>>> [ 0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
>>> [ 0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
>>> .
>>> .
>>> .
>>>
>>> This is caused by code like this in kernel/irq/irqdomain.c
>>>
>>> domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) *
>>> size),
>>> GFP_KERNEL, of_node_to_nid(of_node));
>>>
>>> When NUMA is disabled, the concept of a node is really undefined, so
>>> of_node_to_nid() should unconditionally return NUMA_NO_NODE.
>>>
>>> Fix by returning NUMA_NO_NODE when the nid is not in the set of
>>> possible nodes.
>>>
>>> Reported-by: Gilbert Netzer <noname@pdc.kth.se>
>>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>>
>> Does this need to go in 4.9?
>
>
> That would be my preference.
Given how late this is now, my having nothing else for 4.9 and that
his has never worked, I've applied for 4.10, but I did tag for stable.
Rob
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-10 20:52 UTC (permalink / raw)
To: Balbir Singh
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <aea94234-b3d8-1484-d3ab-39e562d7901d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 10, 2016 at 11:56:02AM +1100, Balbir Singh wrote:
>Have you tested this across all combinations of skiboot/kexec/SLOF
>boots?
I've tested it under qemu/grub, simics/skiboot, and via kexec.
--
Reza Arbab
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/12] of: Make drivers/of/resolver.c more readable
From: Rob Herring @ 2016-11-10 20:56 UTC (permalink / raw)
To: frowand.list
Cc: pantelis.antoniou, Pantelis Antoniou, devicetree, linux-kernel
In-Reply-To: <1477722392-32172-1-git-send-email-frowand.list@gmail.com>
On Fri, Oct 28, 2016 at 11:26:20PM -0700, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@am.sony.com>
>
> drivers/of/resolve.c is a bit difficult to read. Clean it up so
> that review of future overlay related patches will be easier.
>
> Most of the patches are intended to be reformatting, with no functional
> change. Patches that are expected to have a functional change are:
>
> Remove excessive printks to reduce clutter.
> Update structure of code to be clearer, also remove BUG_ON()
> Any functional change would reflect undefined behavior on bad overlay.
> Some error message text modified.
> BUG_ON() removed.
> Add back an error message, restructured
>
> The patches are grouped into sets of changes that are intended
> to be easy to verify correctness through simple inspection.
>
> Some of the individual patches have checkpatch warnings or errors.
> But after all patches are applied, the number of errors and
> warnings from running checkpatch against the entire file are
> reduced to two line size warnings.
>
> These patches are only tested via the unit tests. I do not have
> expansion boards to test with real hardware.
>
> changes from rfc to v1:
> - Remove fewer one line comments
> - Add more extensive header comment to of_resolve_phandles()
> to explain the how and why of resolving phandles
> - Update patch header comments
> - Incorporated patch "Remove braces around single line blocks"
> into the previous patch in the series
>
>
> Frank Rowand (12):
> of: Remove comments that state the obvious, to reduce clutter
> of: Remove excessive printks to reduce clutter.
> of: Convert comparisons to zero or NULL to logical expressions
> of: Rename functions to more accurately reflect what they do
> of: Remove prefix "__of_" from local function names
> of: Rename variables to better reflect purpose or follow convention
> of: Update structure of code to be clearer, also remove BUG_ON()
> of: Remove redundant size check
> of: Update comments to reflect changes and increase clarity
> of: Add back an error message, restructured
> of: Move setting of pointer to beside test for non-null
> of: Remove unused variable overlay_symbols
Series applied.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] of/platform: fix of_platform_device_destroy comment
From: Rob Herring @ 2016-11-10 20:56 UTC (permalink / raw)
To: Johan Hovold; +Cc: Frank Rowand, devicetree, linux-kernel
In-Reply-To: <1477997602-29652-1-git-send-email-johan@kernel.org>
On Tue, Nov 01, 2016 at 11:53:21AM +0100, Johan Hovold wrote:
> Update the comment to of_platform_device_destroy() to reflect that it no
> longer returns a status value.
>
> Fixes: 75f353b61342 ("of/platform: Fix of_platform_device_destroy...")
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/of/platform.c | 3 ---
> 1 file changed, 3 deletions(-)
Both patches applied.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: stm32-adc: Add support for stm32 ADC
From: kbuild test robot @ 2016-11-10 21:23 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg,
fabrice.gasnier-qxv4g6HH51o
In-Reply-To: <1478794738-28933-3-git-send-email-fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
Hi Fabrice,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Fabrice-Gasnier/Add-support-for-STM32-ADC/20161111-011922
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All errors (new ones prefixed by >>):
drivers/mfd/stm32-adc-core: struct of_device_id is 200 bytes. The last of 1 is:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x66 0x34 0x2d 0x61 0x64 0x63 0x2d 0x63 0x6f 0x72 0x65 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> FATAL: drivers/mfd/stm32-adc-core: struct of_device_id is not terminated with a NULL entry!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43228 bytes --]
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Benjamin Herrenschmidt @ 2016-11-10 21:28 UTC (permalink / raw)
To: Guilherme G. Piccoli, devicetree
Cc: linux-pci, robh+dt, linuxppc-dev, frowand.list
In-Reply-To: <1478700308-25481-1-git-send-email-gpiccoli@linux.vnet.ibm.com>
On Wed, 2016-11-09 at 12:05 -0200, Guilherme G. Piccoli wrote:
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 393fea8..1ad6882 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -275,7 +275,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> of_node_put(ipar);
> of_node_put(newpar);
>
> - return -EINVAL;
> + /* Positive non-zero return means no Level-triggered Interrupts
> + * capability was found.
> + */
> + return ENOENT;
> }
> EXPORT_SYMBOL_GPL(of_irq_parse_raw);
I'm not fan. I'd rather it's -ENOENT and the callers can check for that
specific code rather than playing with the sign.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Benjamin Herrenschmidt @ 2016-11-10 21:30 UTC (permalink / raw)
To: Mark Rutland, Guilherme G. Piccoli
Cc: devicetree, marc.zyngier, frowand.list, robh+dt, linux-pci,
linuxppc-dev
In-Reply-To: <20161109190457.GC837@leverpostej>
On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote:
>
>
> If we don't have an interrupt-map on a PCI controller, why don't we
> instead log a message regarding that being missing, and give up
> early?
Why ? It's legit to not support LSIs.
> That sounds like a more generically useful error message; it's also
> possible that a DT author simply forgot to add the map, and the
> platform has suitable interrupts wired up.
But it's not necessarily an error...
> > This patch introduces a different message for this specific case,
> > and it also reduces the level of the message from error to warning.
> > Before this patch, when an adapter was plugged in a slot without
> Level
> > interrupts capabilities, we saw generic error messages like this:
> >
> > [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-
> 22
> >
> > Now, with this applied, we see the following specific message:
> >
> > [19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot
> of this
> > device has no Level-triggered Interrupts capability.
>
> Following my above example, this has gone from opaque to potentially
> misleading
I'm not sure. At least for some of our platforms this is the correct
message :-) Our Hypervisor doesn't allow LSIs on some slots.
I think it's not that misleading. It's obvious something is wrong with
LSIs, which you can easily figure out from there.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Rob Herring @ 2016-11-10 21:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Peter Chen, Stephen Boyd, Greg KH, Arnd Bergmann, Neil Armstrong,
linux-arm-msm, linux-usb, linux-kernel, Bjorn Andersson,
Peter Chen, linux-arm-kernel, Andy Gross, devicetree,
Felipe Balbi
In-Reply-To: <CAGb2v66C15fU1b2+xNDV8Fv2kmmKXyUknA8=9wXztUcs8CNKLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Nov 6, 2016 at 7:56 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> > > > > Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Anup Patel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> index be56d2b..954561d 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> @@ -7,6 +7,15 @@ Required properties:
> - compatible : Should be one of the following
> "brcm,bcm2835-sdhci"
> "brcm,sdhci-iproc-cygnus"
> + "brcm,sdhci-iproc"
> +
> +Use brcm2835-sdhci for Rasperry PI.
> +
> +Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
> +restricted to 32bit host accesses to SDHCI registers.
> +
> +Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
> +8, 16, 32-bit host access to SDHCI register.
>
> - clocks : The clock feeding the SDHCI controller.
>
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Srinath Mannam
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-iproc.c | 35 +++++++++++++++++++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 7262466..d7046d6 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -143,6 +143,14 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
> }
>
> static const struct sdhci_ops sdhci_iproc_ops = {
> + .set_clock = sdhci_set_clock,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
> +static const struct sdhci_ops sdhci_iproc_32only_ops = {
> .read_l = sdhci_iproc_readl,
> .read_w = sdhci_iproc_readw,
> .read_b = sdhci_iproc_readb,
> @@ -156,6 +164,28 @@ static const struct sdhci_ops sdhci_iproc_ops = {
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> +static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> + .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> + .ops = &sdhci_iproc_32only_ops,
> +};
> +
> +static const struct sdhci_iproc_data iproc_cygnus_data = {
> + .pdata = &sdhci_iproc_cygnus_pltfm_data,
> + .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> + & SDHCI_MAX_BLOCK_MASK) |
> + SDHCI_CAN_VDD_330 |
> + SDHCI_CAN_VDD_180 |
> + SDHCI_CAN_DO_SUSPEND |
> + SDHCI_CAN_DO_HISPD |
> + SDHCI_CAN_DO_ADMA2 |
> + SDHCI_CAN_DO_SDMA,
> + .caps1 = SDHCI_DRIVER_TYPE_C |
> + SDHCI_DRIVER_TYPE_D |
> + SDHCI_SUPPORT_DDR50,
> + .mmc_caps = MMC_CAP_1_8V_DDR,
> +};
> +
> static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
> .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> @@ -182,7 +212,7 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
> .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_MISSING_CAPS,
> - .ops = &sdhci_iproc_ops,
> + .ops = &sdhci_iproc_32only_ops,
> };
>
> static const struct sdhci_iproc_data bcm2835_data = {
> @@ -194,7 +224,8 @@ static const struct sdhci_iproc_data bcm2835_data = {
>
> static const struct of_device_id sdhci_iproc_of_match[] = {
> { .compatible = "brcm,bcm2835-sdhci", .data = &bcm2835_data },
> - { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_data },
> + { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_cygnus_data},
> + { .compatible = "brcm,sdhci-iproc", .data = &iproc_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH V6 2/6] dt-bindings: qcom: clocks: Add msm8994 clock bindings
From: Stephen Boyd @ 2016-11-10 22:31 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, mail-LJ92rlH3Dns,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michael.scott-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478292996-29559-3-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/04, Jeremy McNicoll wrote:
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-qcom-8994 in clk tree.
> +
> +/* Indexes for GDSCs */
> +#define BIMC_GDSC 0
> +#define VENUS_GDSC 1
> +#define MDSS_GDSC 2
> +#define JPEG_GDSC 3
> +#define VFE_GDSC 4
> +#define OXILI_GDSC 5
> +
But I removed these because it's copy/paste from 8916 and that is
a different family of chips than 8994 so these GDSCs aren't in
GCC on 8994.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V6 5/6] msm8994 clocks: global clock support for msm8994 SOC.
From: Stephen Boyd @ 2016-11-10 22:31 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, mail-LJ92rlH3Dns,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michael.scott-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478292996-29559-6-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/04, Jeremy McNicoll wrote:
> From: Bastian Köcher <mail-LJ92rlH3Dns@public.gmane.org>
>
> The clock definition was ported from the Google 3.10 kernel tree to
> work with the latest kernel.
>
> Signed-off-by: Bastian Köcher <mail-LJ92rlH3Dns@public.gmane.org>
> [jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org: created new commit of just dt-bindings]
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-qcom-8994 in clk tree
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
From: Stephen Boyd @ 2016-11-10 22:51 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Brown, Rafael Wysocki, nm, Viresh Kumar, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh, d-gerlach,
devicetree
In-Reply-To: <20161110180940.GD11670@vireshk-i7>
On 11/10, Viresh Kumar wrote:
> On 10-11-16, 16:36, Mark Brown wrote:
> > On Thu, Nov 10, 2016 at 09:34:40AM +0530, Viresh Kumar wrote:
> > > On 09-11-16, 14:58, Mark Brown wrote:
> > > > On Wed, Oct 26, 2016 at 12:02:56PM +0530, Viresh Kumar wrote:
> >
> > > > > + Entries for multiple regulators shall be provided in the same field separated
> > > > > + by angular brackets <>. The OPP binding doesn't provide any provisions to
> > > > > + relate the values to their power supplies or the order in which the supplies
> > > > > + need to be configured.
> >
> > > > I don't understand how this works. If we have an unordered list of
> > > > values to set for regulators how will we make sense of them?
> >
> > > The platform driver is responsible to identify the order and pass it on to the
> > > OPP core. And the platform driver needs to have that hard coded.
> >
> > That *really* should be in the binding.
>
> Okay, how do you suggest doing that? Will a property like supply-names
> in the OPP table be fine? Like this:
>
> @@ -369,13 +378,16 @@ Example 4: Handling multiple regulators
> compatible = "arm,cortex-a7";
> ...
>
> - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
> + vcc0-supply = <&cpu_supply0>;
> + vcc1-supply = <&cpu_supply1>;
> + vcc2-supply = <&cpu_supply2>;
> operating-points-v2 = <&cpu0_opp_table>;
> };
> };
>
> cpu0_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> + supply-names = "vcc0", "vcc1", "vcc2";
> opp-shared;
>
No. The supply names (and also clock names/index) should be left
up to the consumer of the OPP table. We don't want to encode any
sort of details like this between the OPP table and the consumer
of it in DT because then it seriously couples the OPP table to
the consumer device. "The binding" in this case that needs to be
updated is the consumer binding, to indicate that it correlated
foo-supply and bar-supply to index 0 and 1 of the OPP table
voltages.
--
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