Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Rick Chang @ 2016-12-12  9:07 UTC (permalink / raw)
  To: Ricky Liang
  Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
	Matthias Brugger, Rob Herring, open list, linux-media,
	srv_heupstream, moderated list:ARM/Mediatek SoC...,
	moderated list:ARM/Mediatek SoC...,
	open list:OPEN FIRMWARE AND..., Minghsiu Tsai, Bin Liu
In-Reply-To: <CAAJzSMfNyMiia==mXKo6aBw1VxMBxGE20LB870Zm1u9mCoioyQ@mail.gmail.com>

Hi Ricky,

Thanks for your feedback. We will fix the problem in another patch.

On Mon, 2016-12-12 at 12:34 +0800, Ricky Liang wrote:
> Hi Rick,
> 
> On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang@mediatek.com> wrote:
> > Add v4l2 driver for Mediatek JPEG Decoder
> >
> > Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> 
> <snip...>
> 
> > +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> > +                                            struct mtk_jpeg_dec_param *param)
> > +{
> > +       struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > +       struct mtk_jpeg_q_data *q_data;
> > +
> > +       q_data = &ctx->out_q;
> > +       if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> > +               v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> > +               return true;
> > +       }
> > +
> > +       q_data = &ctx->cap_q;
> > +       if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> > +                                               MTK_JPEG_FMT_TYPE_CAPTURE)) {
> > +               v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> > +               return true;
> > +       }
> > +       return false;
> 
> <snip...>
> 
> > +static void mtk_jpeg_device_run(void *priv)
> > +{
> > +       struct mtk_jpeg_ctx *ctx = priv;
> > +       struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > +       struct vb2_buffer *src_buf, *dst_buf;
> > +       enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> > +       unsigned long flags;
> > +       struct mtk_jpeg_src_buf *jpeg_src_buf;
> > +       struct mtk_jpeg_bs bs;
> > +       struct mtk_jpeg_fb fb;
> > +       int i;
> > +
> > +       src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > +       dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > +       jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> > +
> > +       if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> > +               for (i = 0; i < dst_buf->num_planes; i++)
> > +                       vb2_set_plane_payload(dst_buf, i, 0);
> > +               buf_state = VB2_BUF_STATE_DONE;
> > +               goto dec_end;
> > +       }
> > +
> > +       if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> > +               mtk_jpeg_queue_src_chg_event(ctx);
> > +               ctx->state = MTK_JPEG_SOURCE_CHANGE;
> > +               v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > +               return;
> > +       }
> 
> This only detects source change if multiple OUPUT buffers are queued.
> It does not catch the source change in the following scenario:
> 
> - OUPUT buffers for jpeg1 enqueued
> - OUTPUT queue STREAMON
> - userspace creates CAPTURE buffers
> - CAPTURE buffers enqueued
> - CAPTURE queue STREAMON
> - decode
> - OUTPUT queue STREAMOFF
> - userspace recreates OUTPUT buffers for jpeg2
> - OUTPUT buffers for jpeg2 enqueued
> - OUTPUT queue STREAMON
> 
> In the above sequence if jpeg2's decoded size is larger than jpeg1 the
> function fails to detect that the existing CAPTURE buffers are not big
> enough to hold the decoded data.
> 
> A possible fix is to pass *dst_buf to
> mtk_jpeg_check_resolution_change(), and check in the function that all
> the dst_buf planes are large enough to hold the decoded data.
> 
> > +
> > +       mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> > +       if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> > +               goto dec_end;
> > +
> > +       spin_lock_irqsave(&jpeg->hw_lock, flags);
> > +       mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> > +       mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> > +                               &jpeg_src_buf->dec_param, &bs, &fb);
> > +
> > +       mtk_jpeg_dec_start(jpeg->dec_reg_base);
> > +       spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> > +       return;
> > +
> > +dec_end:
> > +       v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > +       v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > +       v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> > +       v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> > +       v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > +}
> 
> <snip...>

^ permalink raw reply

* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Thang Q. Nguyen @ 2016-12-12  8:55 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
	Mathias Nyman, Greg Kroah-Hartman,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, Phong Vo, Loc Ho, Vu Nguyen,
	patches
In-Reply-To: <87lgvliluh.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

Hi,

On Mon, Dec 12, 2016 at 3:37 PM, Felipe Balbi
<felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> Hi,
>
> "Thang Q. Nguyen" <tqnguyen-qTEPVZfXA3Y@public.gmane.org> writes:
>> On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>>>> From: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
>>>>
>>>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>>>> device or host initiated via resume signaling; device-initiated resumes
>>>> can be optionally enabled/disabled by software. This patch adds support
>>>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>>>
>>>> Signed-off-by: Vu Nguyen <vnguyen-qTEPVZfXA3Y@public.gmane.org>
>>>> Signed-off-by: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>>>  drivers/usb/host/xhci-plat.c                       | 3 +++
>>>>  drivers/usb/host/xhci.c                            | 5 ++++-
>>>>  drivers/usb/host/xhci.h                            | 1 +
>>>>  4 files changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> index 966885c..9b4cd14 100644
>>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> @@ -25,6 +25,7 @@ Required properties:
>>>>
>>>>  Optional properties:
>>>>    - clocks: reference to a clock
>>>> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>>>
>>> Remote wakeup has been around since USB 1.0 days. Does this need to be
>>> USB2 or XHCI specific?
>> This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
>> optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
>> ability for software to disable RWE for USB2 in XHCI1.0 controller.
>
> is there no way of detecting this in runtime?
Current driver always enable remote wakeup when the controller and USB
support this feature. However, per the Errata, software can optionally
enable/disable this.
Some XHCI-1.0-compatible controller does not implement features such
as HIRD, BESL which are optional for XHCI 1.1 will be fail to work
with USB2.0 device that require long time to resume from suspend.
Disabling remote wakeup by software will make this case not happen.
>
> --
> balbi



-- 

Thang Q. Nguyen    | Staff SW Eng.

C: +849.7684.7606 | O: +848.3770.0640

F: +848.3770.0641  | tqnguyen-qTEPVZfXA3Y@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 v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Jiri Kosina @ 2016-12-12  8:53 UTC (permalink / raw)
  To: Rob Herring
  Cc: Dmitry Torokhov, Benjamin Tissoires, Doug Anderson, Brian Norris,
	Caesar Wang, open list:ARM/Rockchip SoC...,
	linux-input@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, Mark Rutland
In-Reply-To: <CAL_JsqLpjhHeeKq3PmNToux1Rgkg0M84-dv9HGCOws223ima4w@mail.gmail.com>

Given the timing (merge window being open) and given then NACK given by 
Rob, I've now unapplied the patches (the for-4.10/i2c-hid branch is now 
obsolete, and has been superseded by for-4.10/i2c-hid-nopower).

However, this is mostly done in order to provide more time for discussion; 
I still disagree with the reasoning behind the NACK.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Felipe Balbi @ 2016-12-12  8:37 UTC (permalink / raw)
  To: Thang Q. Nguyen, Rob Herring
  Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Mathias Nyman,
	Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, Phong Vo, Loc Ho, Vu Nguyen,
	patches
In-Reply-To: <CAKrQpStd4+ZZjdYyq93zq-wnqQCiQmSi5jJrYbuiZX5kVH74YA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]


Hi,

"Thang Q. Nguyen" <tqnguyen-qTEPVZfXA3Y@public.gmane.org> writes:
> On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>>> From: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
>>>
>>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>>> device or host initiated via resume signaling; device-initiated resumes
>>> can be optionally enabled/disabled by software. This patch adds support
>>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>>
>>> Signed-off-by: Vu Nguyen <vnguyen-qTEPVZfXA3Y@public.gmane.org>
>>> Signed-off-by: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
>>> ---
>>>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>>  drivers/usb/host/xhci-plat.c                       | 3 +++
>>>  drivers/usb/host/xhci.c                            | 5 ++++-
>>>  drivers/usb/host/xhci.h                            | 1 +
>>>  4 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> index 966885c..9b4cd14 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> @@ -25,6 +25,7 @@ Required properties:
>>>
>>>  Optional properties:
>>>    - clocks: reference to a clock
>>> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>>
>> Remote wakeup has been around since USB 1.0 days. Does this need to be
>> USB2 or XHCI specific?
> This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
> optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
> ability for software to disable RWE for USB2 in XHCI1.0 controller.

is there no way of detecting this in runtime?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply

* Re: [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-12  8:34 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: Rob Herring, Maxime Coquelin, Alexandre Torgue, Linus Walleij,
	Patrice Chotard, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161211214232.GA2552@katana>

Hi Wolfram,

Thanks for your comments.
I will fix all of them + build errors reported by build-bot in the V6.

Best regards,

Cedric Madianga

2016-12-11 22:42 GMT+01:00 Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>:
> Hi,
>
>> +config I2C_STM32F4
>> +     tristate "STMicroelectronics STM32F4 I2C support"
>> +     depends on ARCH_STM32  || COMPILE_TEST
>
> Double space.
>
>> +#define STM32F4_I2C_MIN_FREQ         2
>> +#define STM32F4_I2C_MAX_FREQ         42
>
> Those two must be unsigned to fix the build error (e.g. 2U) reported by
> build-bot.
>
> Also, I get the following build warnings:
>
>   CC      drivers/i2c/busses/i2c-stm32f4.o
> drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_handle_rx_addr’:
> drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ‘sr2’ set but not used [-Wunused-but-set-variable]
>   u32 sr2;
>       ^~~
> drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_isr_event’:
> drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ‘sr2’ set but not used [-Wunused-but-set-variable]
>   u32 real_status, possible_status, ien, sr2;
>
> I assume those are reads to clear the register, so we really don't need
> to save the value in a variable.
>
> Rest is looking good.
>
> Thanks,
>
>    Wolfram
>
--
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 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-12-12  8:07 UTC (permalink / raw)
  To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>

Hi all,

I forgot to add a question to my cover letter so here it is:

The X-Powers AXP209 and AXP223 PMICs allow to not limit the maximal
current for the VBUS power supply.[1]
(If a Chinese-speaking person could check it's the same for the AXP221
that would be great also[2]).

In the get_property (axp20x_usb_power_get_property) of the power supply
driver, I see that we use -1 as value for "no limit". Should we use the
same (-1) value for the set_property (axp20x_usb_power_set_property) to
disable max current limit?

[1] http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf page 33,
REG 30H, BITS 0 & 1
[2]
http://dl.linux-sunxi.org/AXP/AXP221%20Datasheet%20V1.2%2020130326%20.pdf
page 33, REG 30H, BITS 0 & 1 => 不限流 is written for when the BIT(1) is
set.

Thanks,
Quentin

On 09/12/2016 12:04, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
> 
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
> 
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
> 
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
> 
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
> 
> Quentin Schulz (11):
>   power: supply: axp20x_usb_power: use of_device_id data field instead
>     of device_is_compatible
>   mfd: axp20x: add volatile and writeable reg ranges for VBUS power
>     supply driver
>   power: supply: axp20x_usb_power: set min voltage and max current from
>     sysfs
>   Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
>   power: supply: axp20x_usb_power: add 100mA max current limit for
>     AXP223
>   mfd: axp20x: add separate MFD cell for AXP223
>   ARM: dtsi: add DTSI for AXP223
>   ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
>   ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
>   ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
>   ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
> 
>  .../bindings/power/supply/axp20x_usb_power.txt     |   5 +
>  arch/arm/boot/dts/axp223.dtsi                      |  58 +++++++++++
>  arch/arm/boot/dts/sun8i-a33-olinuxino.dts          |   2 +-
>  arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts     |   2 +-
>  arch/arm/boot/dts/sun8i-r16-parrot.dts             |   2 +-
>  .../boot/dts/sun8i-reference-design-tablet.dtsi    |   2 +-
>  drivers/mfd/axp20x.c                               |  32 +++++-
>  drivers/power/supply/axp20x_usb_power.c            | 116 ++++++++++++++++++---
>  8 files changed, 197 insertions(+), 22 deletions(-)
>  create mode 100644 arch/arm/boot/dts/axp223.dtsi
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2016-12-12  7:48 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
	knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
	pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
	arnaud.pouliquen-qxv4g6HH51o,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1481292919-26587-1-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>

On Fri, 09 Dec 2016, Benjamin Gaignard wrote:

> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
> 
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
> 
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
> 
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
> 
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
>   - pwm channels, complementary output, counter size, break input
>   - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
> 
> The following patches enable PWM and IIO Timer features for STM32 platforms.
> 
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver 
> on the top of them to be able to share the registers.
> 
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to 
> describe the differences between hardware blocks
> 
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
> 
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
> 
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers. 
> 
> The matrix of possible connections between blocks is quite complex so we use 
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
> 
> At run time IIO timer hardware blocks can configure (through "master_mode" 
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
> 
> By using "slave_mode" IIO device attribute timer can also configure on which
> event (level, rising edge) of the block is enabled.
> 
> Since we can use trigger from one hardware to control an other block, we can
> use a pwm to control an other one. The following example shows how to configure
> pwm1 and pwm3 to make pwm3 generate pulse only when pwm1 pulse level is high.
> 
> /sys/bus/iio/devices # ls
> iio:device0  iio:device1  trigger0     trigger1
> 
> configure timer1 to use pwm1 channel 0 as output trigger
> /sys/bus/iio/devices # echo 'OC1REF' > iio\:device0/master_mode
> configure timer3 to enable only when input is high
> /sys/bus/iio/devices # echo 'gated' > iio\:device1/slave_mode
> /sys/bus/iio/devices # cat trigger0/name
> tim1_trgo
> configure timer2 to use timer1 trigger is input
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
> 
> configure pwm3 channel 0 to generate a signal with a period of 100ms and a
> duty cycle of 50%
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 100000000 > pwm0/period
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
> here pwm3 channel 0, as expected, doesn't start because has to be triggered by
> pwm1 channel 0
> 
> configure pwm1 channel 0 to generate a signal with a period of 1s and a
> duty cycle of 50%
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 0 > export
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1000000000 > pwm0/period
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1 > pwm0/enable 
> finally pwm1 starts and pwm3 only generates pulse when pwm1 signal is high
> 
> An other example to use a timer as source of clock for another device.
> Here timer1 is used a source clock for pwm3:
> 
> /sys/bus/iio/devices # echo 100000 > trigger0/sampling_frequency 
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger 
> /sys/bus/iio/devices # echo 'external_clock' > iio\:device1/slave_mode
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export 
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1000000 > pwm0/period 
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle 
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
> 
> Benjamin Gaignard (8):
>   MFD: add bindings for STM32 Timers driver
>   MFD: add STM32 Timers driver
>   PWM: add pwm-stm32 DT bindings
>   PWM: add PWM driver for STM32 plaftorm
>   IIO: add bindings for STM32 timer trigger driver
>   IIO: add STM32 timer trigger driver
>   ARM: dts: stm32: add Timers driver for stm32f429 MCU
>   ARM: dts: stm32: Enable pw1 and pwm3 for stm32f469-disco
> 
>  .../ABI/testing/sysfs-bus-iio-timer-stm32          |  55 +++
>  .../bindings/iio/timer/stm32-timer-trigger.txt     |  23 +
>  .../devicetree/bindings/mfd/stm32-timers.txt       |  46 ++
>  .../devicetree/bindings/pwm/pwm-stm32.txt          |  33 ++
>  arch/arm/boot/dts/stm32f429.dtsi                   | 275 ++++++++++++
>  arch/arm/boot/dts/stm32f469-disco.dts              |  28 ++
>  drivers/iio/Kconfig                                |   2 +-
>  drivers/iio/Makefile                               |   1 +
>  drivers/iio/timer/Kconfig                          |  13 +
>  drivers/iio/timer/Makefile                         |   1 +
>  drivers/iio/timer/stm32-timer-trigger.c            | 466 +++++++++++++++++++++
>  drivers/iio/trigger/Kconfig                        |   1 -
>  drivers/mfd/Kconfig                                |  11 +
>  drivers/mfd/Makefile                               |   2 +
>  drivers/mfd/stm32-timers.c                         |  80 ++++
>  drivers/pwm/Kconfig                                |   9 +
>  drivers/pwm/Makefile                               |   1 +
>  drivers/pwm/pwm-stm32.c                            | 434 +++++++++++++++++++
>  include/linux/iio/timer/stm32-timer-trigger.h      |  62 +++
>  include/linux/mfd/stm32-timers.h                   |  71 ++++
>  20 files changed, 1612 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>  create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>  create mode 100644 drivers/iio/timer/Kconfig
>  create mode 100644 drivers/iio/timer/Makefile
>  create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
>  create mode 100644 drivers/mfd/stm32-timers.c
>  create mode 100644 drivers/pwm/pwm-stm32.c
>  create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>  create mode 100644 include/linux/mfd/stm32-timers.h

This has really come together nicely.

Great work Benjamin.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/8] MFD: add STM32 Timers driver
From: Lee Jones @ 2016-12-12  7:47 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: robh+dt, mark.rutland, alexandre.torgue, devicetree, linux-kernel,
	thierry.reding, linux-pwm, jic23, knaack.h, lars, pmeerw,
	linux-iio, linux-arm-kernel, fabrice.gasnier, gerald.baeza,
	arnaud.pouliquen, linus.walleij, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1481292919-26587-3-git-send-email-benjamin.gaignard@st.com>

On Fri, 09 Dec 2016, Benjamin Gaignard wrote:

> This hardware block could at used at same time for PWM generation
> and IIO timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
> 
> version 6:
> - rename files to stm32-timers
> - rename functions to stm32_timers_xxx
> 
> version 5:
> - fix Lee comments about detect function
> - add missing dependency on REGMAP_MMIO
> 
> version 4:
> - add a function to detect Auto Reload Register (ARR) size
> - rename the structure shared with other drivers
> 
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
>  drivers/mfd/Kconfig              | 11 ++++++
>  drivers/mfd/Makefile             |  2 +
>  drivers/mfd/stm32-timers.c       | 80 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/mfd/stm32-timers.h | 71 +++++++++++++++++++++++++++++++++++
>  4 files changed, 164 insertions(+)
>  create mode 100644 drivers/mfd/stm32-timers.c
>  create mode 100644 include/linux/mfd/stm32-timers.h

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df644..4ec1906 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1607,6 +1607,17 @@ config MFD_STW481X
>  	  in various ST Microelectronics and ST-Ericsson embedded
>  	  Nomadik series.
>  
> +config MFD_STM32_TIMERS
> +	tristate "Support for STM32 Timers"
> +	depends on (ARCH_STM32 && OF) || COMPILE_TEST
> +	select MFD_CORE
> +	select REGMAP
> +	select REGMAP_MMIO
> +	help
> +	  Select this option to enable STM32 timers driver used
> +	  for PWM and IIO Timer. This driver allow to share the
> +	  registers between the others drivers.
> +
>  menu "Multimedia Capabilities Port drivers"
>  	depends on ARCH_SA1100
>  
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..11a52f8 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,5 @@ obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397)	+= mt6397-core.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)	+= altera-a10sr.o
> +
> +obj-$(CONFIG_MFD_STM32_TIMERS) 	+= stm32-timers.o
> diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
> new file mode 100644
> index 0000000..68d115e
> --- /dev/null
> +++ b/drivers/mfd/stm32-timers.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/mfd/stm32-timers.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +
> +static const struct regmap_config stm32_timers_regmap_cfg = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = sizeof(u32),
> +	.max_register = 0x400,
> +};
> +
> +static void stm32_timers_get_arr_size(struct stm32_timers *ddata)
> +{
> +	/*
> +	 * Only the available bits will be written so when readback
> +	 * we get the maximum value of auto reload register
> +	 */
> +	regmap_write(ddata->regmap, TIM_ARR, ~0L);
> +	regmap_read(ddata->regmap, TIM_ARR, &ddata->max_arr);
> +	regmap_write(ddata->regmap, TIM_ARR, 0x0);
> +}
> +
> +static int stm32_timers_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct stm32_timers *ddata;
> +	struct resource *res;
> +	void __iomem *mmio;
> +
> +	ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> +	if (!ddata)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	mmio = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(mmio))
> +		return PTR_ERR(mmio);
> +
> +	ddata->regmap = devm_regmap_init_mmio_clk(dev, "clk_int", mmio,
> +						  &stm32_timers_regmap_cfg);
> +	if (IS_ERR(ddata->regmap))
> +		return PTR_ERR(ddata->regmap);
> +
> +	ddata->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(ddata->clk))
> +		return PTR_ERR(ddata->clk);
> +
> +	stm32_timers_get_arr_size(ddata);
> +
> +	platform_set_drvdata(pdev, ddata);
> +
> +	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +}
> +
> +static const struct of_device_id stm32_timers_of_match[] = {
> +	{ .compatible = "st,stm32-timers", },
> +	{ /* end node */ },
> +};
> +MODULE_DEVICE_TABLE(of, stm32_timers_of_match);
> +
> +static struct platform_driver stm32_timers_driver = {
> +	.probe = stm32_timers_probe,
> +	.driver	= {
> +		.name = "stm32-timers",
> +		.of_match_table = stm32_timers_of_match,
> +	},
> +};
> +module_platform_driver(stm32_timers_driver);
> +
> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timers");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> new file mode 100644
> index 0000000..d030004
> --- /dev/null
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _LINUX_STM32_GPTIMER_H_
> +#define _LINUX_STM32_GPTIMER_H_
> +
> +#include <linux/clk.h>
> +#include <linux/regmap.h>
> +
> +#define TIM_CR1		0x00	/* Control Register 1      */
> +#define TIM_CR2		0x04	/* Control Register 2      */
> +#define TIM_SMCR	0x08	/* Slave mode control reg  */
> +#define TIM_DIER	0x0C	/* DMA/interrupt register  */
> +#define TIM_SR		0x10	/* Status register	   */
> +#define TIM_EGR		0x14	/* Event Generation Reg    */
> +#define TIM_CCMR1	0x18	/* Capt/Comp 1 Mode Reg    */
> +#define TIM_CCMR2	0x1C	/* Capt/Comp 2 Mode Reg    */
> +#define TIM_CCER	0x20	/* Capt/Comp Enable Reg    */
> +#define TIM_PSC		0x28	/* Prescaler               */
> +#define TIM_ARR		0x2c	/* Auto-Reload Register    */
> +#define TIM_CCR1	0x34	/* Capt/Comp Register 1    */
> +#define TIM_CCR2	0x38	/* Capt/Comp Register 2    */
> +#define TIM_CCR3	0x3C	/* Capt/Comp Register 3    */
> +#define TIM_CCR4	0x40	/* Capt/Comp Register 4    */
> +#define TIM_BDTR	0x44	/* Break and Dead-Time Reg */
> +
> +#define TIM_CR1_CEN	BIT(0)	/* Counter Enable	   */
> +#define TIM_CR1_ARPE	BIT(7)	/* Auto-reload Preload Ena */
> +#define TIM_CR2_MMS	(BIT(4) | BIT(5) | BIT(6)) /* Master mode selection */
> +#define TIM_SMCR_SMS	(BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
> +#define TIM_SMCR_TS	(BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
> +#define TIM_DIER_UIE	BIT(0)	/* Update interrupt	   */
> +#define TIM_SR_UIF	BIT(0)	/* Update interrupt flag   */
> +#define TIM_EGR_UG	BIT(0)	/* Update Generation       */
> +#define TIM_CCMR_PE	BIT(3)	/* Channel Preload Enable  */
> +#define TIM_CCMR_M1	(BIT(6) | BIT(5))  /* Channel PWM Mode 1 */
> +#define TIM_CCER_CC1E	BIT(0)	/* Capt/Comp 1  out Ena    */
> +#define TIM_CCER_CC1P	BIT(1)	/* Capt/Comp 1  Polarity   */
> +#define TIM_CCER_CC1NE	BIT(2)	/* Capt/Comp 1N out Ena    */
> +#define TIM_CCER_CC1NP	BIT(3)	/* Capt/Comp 1N Polarity   */
> +#define TIM_CCER_CC2E	BIT(4)	/* Capt/Comp 2  out Ena    */
> +#define TIM_CCER_CC3E	BIT(8)	/* Capt/Comp 3  out Ena    */
> +#define TIM_CCER_CC4E	BIT(12)	/* Capt/Comp 4  out Ena    */
> +#define TIM_CCER_CCXE	(BIT(0) | BIT(4) | BIT(8) | BIT(12))
> +#define TIM_BDTR_BKE	BIT(12) /* Break input enable	   */
> +#define TIM_BDTR_BKP	BIT(13) /* Break input polarity	   */
> +#define TIM_BDTR_AOE	BIT(14)	/* Automatic Output Enable */
> +#define TIM_BDTR_MOE	BIT(15)	/* Main Output Enable      */
> +#define TIM_BDTR_BKF	(BIT(16) | BIT(17) | BIT(18) | BIT(19))
> +#define TIM_BDTR_BK2F	(BIT(20) | BIT(21) | BIT(22) | BIT(23))
> +#define TIM_BDTR_BK2E	BIT(24) /* Break 2 input enable	   */
> +#define TIM_BDTR_BK2P	BIT(25) /* Break 2 input polarity  */
> +
> +#define MAX_TIM_PSC		0xFFFF
> +#define TIM_CR2_MMS_SHIFT	4
> +#define TIM_SMCR_TS_SHIFT	4
> +#define TIM_BDTR_BKF_MASK	0xF
> +#define TIM_BDTR_BKF_SHIFT	16
> +#define TIM_BDTR_BK2F_SHIFT	20
> +
> +struct stm32_timers {
> +	struct clk *clk;
> +	struct regmap *regmap;
> +	u32 max_arr;
> +};
> +#endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Lee Jones @ 2016-12-12  7:46 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
	knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
	pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
	arnaud.pouliquen-qxv4g6HH51o,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>

On Fri, 09 Dec 2016, Benjamin Gaignard wrote:

> Add bindings information for STM32 Timers
> 
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
> 
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> ---
>  .../devicetree/bindings/mfd/stm32-timers.txt       | 46 ++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> +  prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> +  programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg:			Physical base address and length of the controller's
> +			registers.
> +- clock-names: 		Set to "clk_int".
> +- clocks: 		Phandle to the clock used by the timer module.
> +			For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets:		Phandle to the parent reset controller.
> +			See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm:			See ../pwm/pwm-stm32.txt
> +- timer:		See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> +	timers@40010000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "st,stm32-timers";
> +		reg = <0x40010000 0x400>;
> +		clocks = <&rcc 0 160>;
> +		clock-names = "clk_int";
> +
> +		pwm {
> +			compatible = "st,stm32-pwm";
> +			pinctrl-0	= <&pwm1_pins>;
> +			pinctrl-names	= "default";
> +		};
> +
> +		timer {
> +			compatible = "st,stm32-timer-trigger";
> +			reg = <0>;
> +		};
> +	};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH v3 1/5] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Joel Stanley @ 2016-12-12  5:02 UTC (permalink / raw)
  To: Cédric Le Goater, Marek Vasut
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland, Brendan Higgins
In-Reply-To: <1481302167-28044-2-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:

> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 4a682ee0f632..5c0efbd9dd89 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -29,6 +29,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>           Please note that some tools/drivers/filesystems may not work with
>           4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
>
> +config SPI_ASPEED
> +       tristate "Aspeed flash controllers in SPI mode"
> +       depends on ARCH_ASPEED || COMPILE_TEST
> +       depends on HAS_IOMEM && OF
> +       help
> +         This enables support for the Firmware Memory controller (FMC)
> +         in the Aspeed AST2500 SoC when attached to SPI NOR chips,
> +         and support for the SPI flash memory controller (SPI) for
> +         the host firmware. The implementation only supports SPI NOR.
> +
>  config SPI_ATMEL_QUADSPI
>         tristate "Atmel Quad SPI Controller"
>         depends on ARCH_AT91 || (ARM && COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 121695e83542..d73d772c689c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_MTD_SPI_NOR)      += spi-nor.o
> +obj-$(CONFIG_SPI_ASPEED)       += aspeed-smc.o

Can we make the symbol CONFIG_SPI_ASPEED_SMC?

Brendan has proposed a generic SPI master driver for the Aspeed SoC
that would allow the controller to be used for non-flash devices. The
obvious symbol for that driver is CONFIG_SPI_ASPEED.

Cheers,

Joel
--
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 v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-12  4:34 UTC (permalink / raw)
  To: Rick Chang
  Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
	Matthias Brugger, Rob Herring, open list,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	moderated list:ARM/Mediatek SoC...,
	moderated list:ARM/Mediatek SoC...,
	open list:OPEN FIRMWARE AND..., Minghsiu Tsai, Bin Liu
In-Reply-To: <1480475340-21893-3-git-send-email-rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

Hi Rick,

On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

<snip...>

> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> +                                            struct mtk_jpeg_dec_param *param)
> +{
> +       struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> +       struct mtk_jpeg_q_data *q_data;
> +
> +       q_data = &ctx->out_q;
> +       if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> +               v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> +               return true;
> +       }
> +
> +       q_data = &ctx->cap_q;
> +       if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> +                                               MTK_JPEG_FMT_TYPE_CAPTURE)) {
> +               v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> +               return true;
> +       }
> +       return false;

<snip...>

> +static void mtk_jpeg_device_run(void *priv)
> +{
> +       struct mtk_jpeg_ctx *ctx = priv;
> +       struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> +       struct vb2_buffer *src_buf, *dst_buf;
> +       enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> +       unsigned long flags;
> +       struct mtk_jpeg_src_buf *jpeg_src_buf;
> +       struct mtk_jpeg_bs bs;
> +       struct mtk_jpeg_fb fb;
> +       int i;
> +
> +       src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> +       dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> +       jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> +       if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> +               for (i = 0; i < dst_buf->num_planes; i++)
> +                       vb2_set_plane_payload(dst_buf, i, 0);
> +               buf_state = VB2_BUF_STATE_DONE;
> +               goto dec_end;
> +       }
> +
> +       if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> +               mtk_jpeg_queue_src_chg_event(ctx);
> +               ctx->state = MTK_JPEG_SOURCE_CHANGE;
> +               v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +               return;
> +       }

This only detects source change if multiple OUPUT buffers are queued.
It does not catch the source change in the following scenario:

- OUPUT buffers for jpeg1 enqueued
- OUTPUT queue STREAMON
- userspace creates CAPTURE buffers
- CAPTURE buffers enqueued
- CAPTURE queue STREAMON
- decode
- OUTPUT queue STREAMOFF
- userspace recreates OUTPUT buffers for jpeg2
- OUTPUT buffers for jpeg2 enqueued
- OUTPUT queue STREAMON

In the above sequence if jpeg2's decoded size is larger than jpeg1 the
function fails to detect that the existing CAPTURE buffers are not big
enough to hold the decoded data.

A possible fix is to pass *dst_buf to
mtk_jpeg_check_resolution_change(), and check in the function that all
the dst_buf planes are large enough to hold the decoded data.

> +
> +       mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> +       if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> +               goto dec_end;
> +
> +       spin_lock_irqsave(&jpeg->hw_lock, flags);
> +       mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> +       mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> +                               &jpeg_src_buf->dec_param, &bs, &fb);
> +
> +       mtk_jpeg_dec_start(jpeg->dec_reg_base);
> +       spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> +       return;
> +
> +dec_end:
> +       v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> +       v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +       v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> +       v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> +       v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}

<snip...>
--
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: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Thang Q. Nguyen @ 2016-12-12  4:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Mathias Nyman,
	Greg Kroah-Hartman, devicetree, linux-kernel, linux-usb, Phong Vo,
	Loc Ho, Vu Nguyen, patches
In-Reply-To: <20161209213629.76ixdmr24ln72uaw@rob-hp-laptop>

On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>> From: Thang Nguyen <tqnguyen@apm.com>
>>
>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>> device or host initiated via resume signaling; device-initiated resumes
>> can be optionally enabled/disabled by software. This patch adds support
>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>
>> Signed-off-by: Vu Nguyen <vnguyen@apm.com>
>> Signed-off-by: Thang Nguyen <tqnguyen@apm.com>
>> ---
>>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>  drivers/usb/host/xhci-plat.c                       | 3 +++
>>  drivers/usb/host/xhci.c                            | 5 ++++-
>>  drivers/usb/host/xhci.h                            | 1 +
>>  4 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index 966885c..9b4cd14 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -25,6 +25,7 @@ Required properties:
>>
>>  Optional properties:
>>    - clocks: reference to a clock
>> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>
> Remote wakeup has been around since USB 1.0 days. Does this need to be
> USB2 or XHCI specific?
This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
ability for software to disable RWE for USB2 in XHCI1.0 controller.
>
>>    - usb3-lpm-capable: determines if platform is USB3 LPM capable
>>
>>  Example:



-- 

Thang Q. Nguyen    | Staff SW Eng.

C: +849.7684.7606 | O: +848.3770.0640

F: +848.3770.0641  | tqnguyen@apm.com

^ permalink raw reply

* RE: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12  2:59 UTC (permalink / raw)
  To: Rob Herring
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	p.zabel@pengutronix.de, mturquette@baylibre.com,
	daniel.lezcano@linaro.org, sboyd@codeaurora.org,
	linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
	kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
	tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161209181201.ewcqeqslyf3je7kq@rob-hp-laptop>

> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
> 
> On Fri, Dec 02, 2016 at 02:39:33PM +0800, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> >  .../devicetree/bindings/clock/imx6sll-clock.txt    | 13 ++++++++
> >  .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt       | 37 ++++++++++++++++++++++
> >  2 files changed, 50 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> >  create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
> 
> I thought UltraLite was MX6UL?
> 

Sorry, it is a typo, will fix in V2.

> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > +  entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell.  See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > new file mode 100644
> > index 0000000..096e471
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.tx
> > +++ t
> > @@ -0,0 +1,37 @@
> > +* Freescale i.MX6 UltraLite IOMUX Controller
> 
> ditto
> 

Will fix in V2. Thanks for review.

> > +
> > +Please refer to fsl,imx-pinctrl.txt in this directory for common
> > +binding part and usage.
> > +
> > +Required properties:
> > +- compatible: "fsl,imx6sll-iomuxc"
> > +- fsl,pins: each entry consists of 6 integers and represents the mux
> > +and config
> > +  setting for one pin.  The first 5 integers <mux_reg conf_reg
> > +input_reg mux_val
> > +  input_val> are specified using a PIN_FUNC_ID macro, which can be
> > +found in
> > +  imx6ul-pinfunc.h under device tree source folder.  The last integer
> > +CONFIG is
> > +  the pad setting value like pull-up on this pin.  Please refer to
> > +i.MX6SLL
> > +  Reference Manual for detailed CONFIG settings.
> > +
> > +CONFIG bits definition:
> > +PAD_CTL_LVE			(1 << 22)
> > +PAD_CTL_HYS                     (1 << 16)
> > +PAD_CTL_PUS_100K_DOWN           (0 << 14)
> > +PAD_CTL_PUS_47K_UP              (1 << 14)
> > +PAD_CTL_PUS_100K_UP             (2 << 14)
> > +PAD_CTL_PUS_22K_UP              (3 << 14)
> > +PAD_CTL_PUE                     (1 << 13)
> > +PAD_CTL_PKE                     (1 << 12)
> > +PAD_CTL_ODE                     (1 << 11)
> > +PAD_CTL_SPEED_LOW               (0 << 6)
> > +PAD_CTL_SPEED_MED               (1 << 6)
> > +PAD_CTL_SPEED_HIGH              (3 << 6)
> > +PAD_CTL_DSE_DISABLE             (0 << 3)
> > +PAD_CTL_DSE_260ohm              (1 << 3)
> > +PAD_CTL_DSE_130ohm              (2 << 3)
> > +PAD_CTL_DSE_87ohm               (3 << 3)
> > +PAD_CTL_DSE_65ohm               (4 << 3)
> > +PAD_CTL_DSE_52ohm               (5 << 3)
> > +PAD_CTL_DSE_43ohm               (6 << 3)
> > +PAD_CTL_DSE_37ohm               (7 << 3)
> > +PAD_CTL_SRE_FAST                (1 << 0)
> > +PAD_CTL_SRE_SLOW                (0 << 0)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* RE: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2016-12-12  2:58 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	p.zabel@pengutronix.de, mturquette@baylibre.com,
	daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
	linux-gpio@vger.kernel.org, robh+dt@kernel.org,
	kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
	tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161208225257.GP5423@codeaurora.org>

> Subject: Re: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
> 
> On 12/02, Bai Ping wrote:
> > diff --git a/drivers/clk/imx/clk-imx6sll.c
> > b/drivers/clk/imx/clk-imx6sll.c new file mode 100644 index
> > 0000000..c5219e1
> > --- /dev/null
> > +++ b/drivers/clk/imx/clk-imx6sll.c
> > @@ -0,0 +1,366 @@
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include <dt-bindings/clock/imx6sll-clock.h>
> > +#include <linux/clk.h>
> > +#include <linux/clkdev.h>
> 
> Is this include used?
> 

It seems no use, I will remove it in V2.

> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/types.h>
> 
> Is there an include of clk_provider.h missing?
> 

clk_provider.h is included in below "clk.h".

> > +
> > +#include "clk.h"
> > +
> > +#define BM_CCM_CCDR_MMDC_CH0_MASK	(0x2 << 16)
> > +#define CCDR	0x4
> > +
> > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> 
> const char * const? For all of these names.
> 

ok, I will fix in V2.

> > +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > +}; static const char *pll2_bypass_sels[] = { "pll2",
> > +"pll2_bypass_src", }; static const char *pll3_bypass_sels[] = {
> > +"pll3", "pll3_bypass_src", }; static const char *pll4_bypass_sels[] =
> > +{ "pll4", "pll4_bypass_src", }; static const char *pll5_bypass_sels[]
> > += { "pll5", "pll5_bypass_src", }; static const char
> > +*pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", }; static const
> > +char *pll7_bypass_sels[] = { "pll7", "pll7_bypass_src", }; static
> > +const char *step_sels[] = { "osc", "pll2_pfd2_396m", }; static const
> > +char *pll1_sw_sels[] = { "pll1_sys", "step", }; static const char
> > +*axi_alt_sels[] = { "pll2_pfd2_396m", "pll3_pfd1_540m", }; static
> > +const char *axi_sels[] = {"periph", "axi_alt_sel", }; static const
> > +char *periph_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll2_198m", }; static const char
> > +*periph2_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll4_audio_div", }; static const char
> > +*periph_clk2_sels[] = { "pll3_usb_otg", "osc", "osc", }; static const
> > +char *periph2_clk2_sels[] = { "pll3_usb_otg", "osc", }; static const
> > +char *periph_sels[] = { "periph_pre", "periph_clk2", }; static const
> > +char *periph2_sels[] = { "periph2_pre", "periph2_clk2", }; static
> > +const char *usdhc_sels[] = { "pll2_pfd2_396m", "pll2_pfd0_352m", };
> > +static const char *ssi_sels[] = {"pll3_pfd2_508m", "pll3_pfd3_454m",
> > +"pll4_audio_div", "dummy",}; static const char *spdif_sels[] = {
> > +"pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg",
> > +}; static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5",
> > +"ldb_di0_div_7", }; static const char *ldb_di1_div_sels[] = {
> > +"ldb_di1_div_3_5", "ldb_di1_div_7", }; static const char
> > +*ldb_di0_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
> > +"pll2_pfd2_396m", "pll2_pfd3_594m", "pll2_pfd1_594m",
> > +"pll3_pfd3_454m", }; static const char *ldb_di1_sels[] = {
> > +"pll3_usb_otg", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll2_bus",
> > +"pll3_pfd3_454m", "pll3_pfd2_508m", }; static const char
> > +*lcdif_pre_sels[] = { "pll2_bus", "pll3_pfd3_454m", "pll5_video_div",
> > +"pll2_pfd0_352m", "pll2_pfd1_594m", "pll3_pfd1_540m", }; static const
> > +char *ecspi_sels[] = { "pll3_60m", "osc", }; static const char
> > +*uart_sels[] = { "pll3_80m", "osc", }; static const char
> > +*perclk_sels[] = { "ipg", "osc", }; static const char *lcdif_sels[] =
> > +{ "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg",
> > +"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m",
> > +"pll3_pfd2_508m", }; static const char *epdc_sels[] = { "epdc_podf",
> > +"ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static struct clk *clks[IMX6SLL_CLK_END]; static struct
> > +clk_onecell_data clk_data;
> > +
> > +static int const clks_init_on[] __initconst = {
> 
> static const int is more preferred style.
> 

ok, will fix in V2.

> > +	IMX6SLL_CLK_AIPSTZ1, IMX6SLL_CLK_AIPSTZ2,
> > +	IMX6SLL_CLK_OCRAM, IMX6SLL_CLK_ARM, IMX6SLL_CLK_ROM,
> > +	IMX6SLL_CLK_MMDC_P0_FAST, IMX6SLL_CLK_MMDC_P0_IPG, };
> > +
> > +static struct clk_div_table post_div_table[] = {
> 
> const?
> 

ok, will fix in V2.

> > +	{ .val = 2, .div = 1, },
> > +	{ .val = 1, .div = 2, },
> > +	{ .val = 0, .div = 4, },
> > +	{ }
> > +};
> > +
> > +static struct clk_div_table video_div_table[] = {
> 
> const?
> 

ok. will fix in V2.

> > +	{ .val = 0, .div = 1, },
> > +	{ .val = 1, .div = 2, },
> > +	{ .val = 2, .div = 1, },
> > +	{ .val = 3, .div = 4, },
> > +	{ }
> > +};
> > +
> > +static u32 share_count_audio;
> > +static u32 share_count_ssi1;
> > +static u32 share_count_ssi2;
> > +static u32 share_count_ssi3;
> > +
> > +static void __init imx6sll_clocks_init(struct device_node *ccm_node)
> > +{
> > +	struct device_node *np;
> > +	void __iomem *base;
> > +	int i;
> > +
> > +	clks[IMX6SLL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > +
> > +	clks[IMX6SLL_CLK_CKIL] = of_clk_get_by_name(ccm_node, "ckil");
> > +	clks[IMX6SLL_CLK_OSC] = of_clk_get_by_name(ccm_node, "osc");
> > +
> > +	/* ipp_di clock is external input */
> > +	clks[IMX6SLL_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node,
> "ipp_di0");
> > +	clks[IMX6SLL_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node,
> "ipp_di1");
> > +
> > +	np = of_find_compatible_node(NULL, NULL, "fsl,imx6sll-anatop");
> > +	base = of_iomap(np, 0);
> > +	WARN_ON(!base);
> > +
> > +	clks[IMX6SLL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src",
> base + 0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL2_BYPASS_SRC] = imx_clk_mux("pll2_bypass_src",
> base + 0x30, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL3_BYPASS_SRC] = imx_clk_mux("pll3_bypass_src",
> base + 0x10, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL4_BYPASS_SRC] = imx_clk_mux("pll4_bypass_src",
> base + 0x70, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL5_BYPASS_SRC] = imx_clk_mux("pll5_bypass_src",
> base + 0xa0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL6_BYPASS_SRC] = imx_clk_mux("pll6_bypass_src",
> base + 0xe0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +	clks[IMX6SLL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src",
> base
> > ++ 0x20, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +
> > +	clks[IMX6SLL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS,	 "pll1",
> "pll1_bypass_src", base + 0x00, 0x7f);
> > +	clks[IMX6SLL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2",
> "pll2_bypass_src", base + 0x30, 0x1);
> > +	clks[IMX6SLL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB,	 "pll3",
> "pll3_bypass_src", base + 0x10, 0x3);
> > +	clks[IMX6SLL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV,	 "pll4",
> "pll4_bypass_src", base + 0x70, 0x7f);
> > +	clks[IMX6SLL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV,	 "pll5",
> "pll5_bypass_src", base + 0xa0, 0x7f);
> > +	clks[IMX6SLL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET,	 "pll6",
> "pll6_bypass_src", base + 0xe0, 0x3);
> > +	clks[IMX6SLL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB,	 "pll7",
> "pll7_bypass_src", base + 0x20, 0x3);
> > +
> > +	clks[IMX6SLL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base
> + 0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base
> + 0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL3_BYPASS] = imx_clk_mux_flags("pll3_bypass", base
> + 0x10, 16, 1, pll3_bypass_sels, ARRAY_SIZE(pll3_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL4_BYPASS] = imx_clk_mux_flags("pll4_bypass", base
> + 0x70, 16, 1, pll4_bypass_sels, ARRAY_SIZE(pll4_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL5_BYPASS] = imx_clk_mux_flags("pll5_bypass", base
> + 0xa0, 16, 1, pll5_bypass_sels, ARRAY_SIZE(pll5_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL6_BYPASS] = imx_clk_mux_flags("pll6_bypass", base
> + 0xe0, 16, 1, pll6_bypass_sels, ARRAY_SIZE(pll6_bypass_sels),
> CLK_SET_RATE_PARENT);
> > +	clks[IMX6SLL_PLL7_BYPASS] = imx_clk_mux_flags("pll7_bypass", base
> +
> > +0x20, 16, 1, pll7_bypass_sels, ARRAY_SIZE(pll7_bypass_sels),
> > +CLK_SET_RATE_PARENT);
> > +
> > +	/* Do not bypass PLLs initially */
> > +	clk_set_parent(clks[IMX6SLL_PLL1_BYPASS], clks[IMX6SLL_CLK_PLL1]);
> > +	clk_set_parent(clks[IMX6SLL_PLL2_BYPASS], clks[IMX6SLL_CLK_PLL2]);
> > +	clk_set_parent(clks[IMX6SLL_PLL3_BYPASS], clks[IMX6SLL_CLK_PLL3]);
> > +	clk_set_parent(clks[IMX6SLL_PLL4_BYPASS], clks[IMX6SLL_CLK_PLL4]);
> > +	clk_set_parent(clks[IMX6SLL_PLL5_BYPASS], clks[IMX6SLL_CLK_PLL5]);
> > +	clk_set_parent(clks[IMX6SLL_PLL6_BYPASS], clks[IMX6SLL_CLK_PLL6]);
> > +	clk_set_parent(clks[IMX6SLL_PLL7_BYPASS], clks[IMX6SLL_CLK_PLL7]);
> 
> Can we just put raw register writes here instead? I'd prefer we didn't use clk
> consumer APIs to do things to the clk tree from the providers. The problem
> there being that:
> 
>  1) We're trying to move away from using consumer APIs in  provider drivers.
> It's ok if they're used during probe, but  inside clk_ops is not preferred.
> 
>  2) Even if you have a clk pointer, it may be "orphaned" at the  time of
> registration and so calling the APIs here works now but  eventually we may
> want to return an EPROBE_DEFER error in that  case and this may block that
> effort.
> 
> I suppose if this is the only clk driver on this machine then this last point isn't a
> concern and things are probably ok here.
> 

Using raw register writing has an issue.  The register is modified, but it seems the clock 'parent-child' relationship can 
not match the register setting. The register setting is not bypass the pll, but in debug 'clk_summary', the
pll is bypassed.  

BR

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

^ permalink raw reply

* RE: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12  2:32 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	p.zabel@pengutronix.de, mturquette@baylibre.com,
	daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
	linux-gpio@vger.kernel.org, robh+dt@kernel.org,
	kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
	tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161208225424.GQ5423@codeaurora.org>

> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
> 
> On 12/02, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> >  .../devicetree/bindings/clock/imx6sll-clock.txt    | 13 ++++++++
> >  .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt       | 37 ++++++++++++++++++++++
> 
> Please split the bindings into different patches and put them closer to the
> drivers that use them in the series.

Ok, I will fix it in V2.

> 
> >  2 files changed, 50 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> >  create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > +  entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell.  See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
> 
> Can you add an example node here?
> 

Thanks for review, I will add it in V2. 

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH v3 3/5] mtd: aspeed: used a label property
From: Marek Vasut @ 2016-12-12  2:27 UTC (permalink / raw)
  To: Joel Stanley, Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <CACPK8Xcj4P34-4krGbnimVG89wMcHoRX4XJ66-_7KtAt6-vTkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 12/12/2016 12:46 AM, Joel Stanley wrote:
> On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
>> This can be used to easily identify a chip on a system with multiple
>> chips.
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> 
> Our userspace benefits from having this.
> 
> Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

Shouldn't such thing be part of core code then ?

>> ---
>>  drivers/mtd/spi-nor/aspeed-smc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
>> index 99302b0d7786..9119c0ca86b6 100644
>> --- a/drivers/mtd/spi-nor/aspeed-smc.c
>> +++ b/drivers/mtd/spi-nor/aspeed-smc.c
>> @@ -676,6 +676,8 @@ static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
>>                 nor->prepare = aspeed_smc_prep;
>>                 nor->unprepare = aspeed_smc_unprep;
>>
>> +               mtd->name = of_get_property(child, "label", NULL);
>> +
>>                 ret = aspeed_smc_chip_setup_init(chip, r);
>>                 if (ret)
>>                         break;
>> --
>> 2.7.4
>>


-- 
Best regards,
Marek Vasut
--
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 4/5] mtd: spi-nor: bindings for the Aspeed memory controllers
From: Joel Stanley @ 2016-12-12  0:13 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <1481302167-28044-5-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
>  .../devicetree/bindings/mtd/aspeed-smc.txt         | 51 ++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/aspeed-smc.txt b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> new file mode 100644
> index 000000000000..e2c88cea38f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> @@ -0,0 +1,51 @@
> +* Aspeed Firmware Memory controller
> +* Aspeed SPI Flash Memory Controller
> +
> +The Firmware Memory Controller in the Aspeed AST2500 SoC supports
> +three chip selects, two of which are always of SPI type and the third
> +can be SPI or NOR type flash, but the driver only supports SPI.

As the bindings are a description of the hardware and not the driver,
we might want to reword this. Perhaps "these bindings only describe
SPI"?

Cheers,

Joel

> +
> +The two SPI flash memory controllers in the AST2500 each support two
> +chip selects.
> +
> +Required properties:
> +  - compatible : Should be one of
> +       "aspeed,ast2400-fmc" for the AST2400 Firmware Memory Controller
> +       "aspeed,ast2400-spi" for the AST2400 SPI Flash memory Controller
> +       "aspeed,ast2500-fmc" for the AST2500 Firmware Memory Controller
> +       "aspeed,ast2500-spi" for the AST2500 SPI flash memory controllers
> +
> +  - reg : the first contains the control register location and length,
> +          the second contains the memory window mapping address and length
> +  - #address-cells : must be 1 corresponding to chip select child binding
> +  - #size-cells : must be 0 corresponding to chip select child binding
> +
> +Optional properties:
> +  - interrupts : Should contain the interrupt for the dma device if an
> +    FMC
> +
> +The child nodes are the SPI flash modules which must have a compatible
> +property as specified in bindings/mtd/jedec,spi-nor.txt
> +
> +Optionally, the child node can contain properties for SPI mode (may be
> +ignored):
> +  - spi-max-frequency - max frequency of spi bus
> +
> +
> +Example:
> +fmc: fmc@1e620000 {
> +       compatible = "aspeed,ast2500-fmc";
> +       reg = < 0x1e620000 0x94
> +               0x20000000 0x02000000 >;
> +       #address-cells = <1>;
> +       #size-cells = <0>;
> +       interrupts = <19>;
> +       flash@0 {
> +               reg = < 0 >;
> +               compatible = "jedec,spi-nor";
> +               /* spi-max-frequency = <>; */
> +               /* m25p,fast-read; */
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +       };
> +};
> --
> 2.7.4
>
--
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 2/5] mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
From: Joel Stanley @ 2016-12-12  0:10 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <1481302167-28044-3-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This driver adds mtd support for the Aspeed AST2400 SoC static memory
> controllers:
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>

Good work. It was worth spending the time splitting out the different
controllers I think.

Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

> ---
>  drivers/mtd/spi-nor/Kconfig      |  2 +-
>  drivers/mtd/spi-nor/aspeed-smc.c | 33 +++++++++++++++++++++++++++++++++
>  2 files changed, 34 insertions(+), 1 deletion(-)
--
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/5] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Joel Stanley @ 2016-12-12  0:05 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <1481302167-28044-2-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This driver adds mtd support for the Aspeed AST2500 SoC static memory
> controllers :


> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>

I had a read and it looks good. Once you have addressed Marek's
review, please add:

Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

> ---
>  drivers/mtd/spi-nor/Kconfig      |  10 +
>  drivers/mtd/spi-nor/Makefile     |   1 +
>  drivers/mtd/spi-nor/aspeed-smc.c | 735 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 746 insertions(+)
>  create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
>

> +
> +MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
> +MODULE_AUTHOR("Milton Miller");

You can stick your name here instead, or drop the define.

> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
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 5/5] mtd: spi-nor: add a label property to jedec,spi-nor
From: Joel Stanley @ 2016-12-11 23:47 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <1481302167-28044-6-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This can be used to easily identify a chip on a system with multiple
> chips.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>

This is very useful when writing userspace that wants to select the
mtd device that represents a specific flash chip.

Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 2c91c03e7eb0..b7cd02a3ebe8 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -65,6 +65,7 @@ Optional properties:
>                     all chips and support for it can not be detected at runtime.
>                     Refer to your chips' datasheet to check if this is supported
>                     by your chip.
> +- label : name to assign to mtd. If omitted, the label is the MTD device name.
>
>  Example:
>
> @@ -75,4 +76,5 @@ Example:
>                 reg = <0>;
>                 spi-max-frequency = <40000000>;
>                 m25p,fast-read;
> +               label = "System-firmware";
>         };
> --
> 2.7.4
>
--
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 3/5] mtd: aspeed: used a label property
From: Joel Stanley @ 2016-12-11 23:46 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland
In-Reply-To: <1481302167-28044-4-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This can be used to easily identify a chip on a system with multiple
> chips.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>

Our userspace benefits from having this.

Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

> ---
>  drivers/mtd/spi-nor/aspeed-smc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
> index 99302b0d7786..9119c0ca86b6 100644
> --- a/drivers/mtd/spi-nor/aspeed-smc.c
> +++ b/drivers/mtd/spi-nor/aspeed-smc.c
> @@ -676,6 +676,8 @@ static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
>                 nor->prepare = aspeed_smc_prep;
>                 nor->unprepare = aspeed_smc_unprep;
>
> +               mtd->name = of_get_property(child, "label", NULL);
> +
>                 ret = aspeed_smc_chip_setup_init(chip, r);
>                 if (ret)
>                         break;
> --
> 2.7.4
>
--
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 1/2] i2c: aspeed: added driver for Aspeed I2C
From: Wolfram Sang @ 2016-12-11 22:26 UTC (permalink / raw)
  To: Brendan Higgins
  Cc: vz, clg, mouse, robh+dt, mark.rutland, linux-i2c, devicetree,
	joel, openbmc
In-Reply-To: <1480467618-7497-2-git-send-email-brendanhiggins@google.com>

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Tue, Nov 29, 2016 at 05:00:17PM -0800, Brendan Higgins wrote:
> Added initial master and slave support for Aspeed I2C controller.
> Supports fourteen busses present in ast24xx and ast25xx BMC SoCs by
> Aspeed.
> 
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>

BTW first the bindings patch please, then the driver.

And one seperate question I just stumbled over:

> +	/* Switch from master mode to slave mode. */
> +	func_ctrl_reg_val = aspeed_i2c_read(bus, ASPEED_I2C_FUN_CTRL_REG);
> +	func_ctrl_reg_val &= ~ASPEED_I2CD_MASTER_EN;
> +	func_ctrl_reg_val |= ASPEED_I2CD_SLAVE_EN;
> +	aspeed_i2c_write(bus, func_ctrl_reg_val, ASPEED_I2C_FUN_CTRL_REG);

Can't the hardware work both as master and slave on the same bus?

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH] iio: misc: add a generic regulator driver
From: Bartosz Golaszewski @ 2016-12-11 22:23 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Lars-Peter Clausen, Hartmut Knaack, Peter Meerwald-Stadler,
	Rob Herring, Mark Rutland, linux-iio, linux-devicetree, LKML,
	Kevin Hilman, Patrick Titiano, Neil Armstrong, Liam Girdwood,
	Mark Brown
In-Reply-To: <c028b2fc-7ed1-772c-82e3-b98a25f58ffb@kernel.org>

2016-12-10 19:17 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> On 06/12/16 11:12, Bartosz Golaszewski wrote:
>>
>> I wrote the initial patch quickly and didn't give it much of a
>> thought. Now I realized I completely missed the point and managed to
>> confuse everybody - myself included.
>>
>> So the problem we have is not power-cycling the adc - it's
>> power-cycling the device connected to a probe on which there's an adc.
>> What I was trying to do was adding support for the power-switch on
>> baylibre-acme[1] probes.
>>
>> For example: we have a USB probe on which the VBUS signal goes through
>> a power load switch and than through the adc. The adc (in this case
>> ina226) is always powered on, while the fixed regulator I wanted to
>> enable/disable actually drives the power switch to cut/restore power
>> to the connected USB device i.e. there's no real regulator - just a
>> GPIO driving the power switch.
>>
>> A typical use case is measuring the power consumption of development
>> boards[2]. Rebooting them remotely using acme probes is already done,
>> but we're using the obsolete /sys/class/gpio interface.
>>
>> We're already using libiio to read the measured data from the power
>> monitor, that's why we'd like to use the iio framework for
>> power-cycling the devices as well. My question is: would bridging the
>> regulator framework be the right solution? Should we look for
>> something else? Bridge the GPIO framework instead?
>
> Definitely doesn't fit inside standard scope of IIO - though I can see
> why you were thinking along these lines.
>

Well, it's industrial INPUT/output right? I guess we can consider
power-cycling input in this case. :)

In our particular use case, the main reason for using IIO is having a
single interface (libiio) instead of introducing a new one just for
that (in the form of random sysfs attributes for example), but I'm
sure such power switches could find application elsewhere too
(measuring temperature, while power-cycling some cooling mechanism is
the first thing that comes to mind).

> Mark Brown, any thoughts?
>
> Effectively we are are looking at something that (in general form) might
> be the equivalent of controlling a lab bench supply... So regulators
> at the edge of the known world, with no visibility of what lies beyond.
>

Please consider the two patches I just sent. Instead of regulators,
they add DT bindings for gpio power switches and introduce a simple
iio driver using the gpio consumer API.

Best regards,
Bartosz Golaszewski

^ permalink raw reply

* [PATCH 2/2] iio: misc: add support for GPIO power switches
From: Bartosz Golaszewski @ 2016-12-11 22:21 UTC (permalink / raw)
  To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Rob Herring, Mark Rutland
  Cc: linux-iio, devicetree, linux-kernel, Kevin Hilman,
	Patrick Titiano, Neil Armstrong, Linus Walleij, Alexandre Courbot,
	linux-gpio, Sebastian Reichel, linux-pm, Mark Brown,
	Liam Girdwood, Bartosz Golaszewski
In-Reply-To: <1481494905-18037-1-git-send-email-bgolaszewski@baylibre.com>

Some power-measuring ADCs work together with power load switches which
allow to power-cycle measured devices.

An example use case would be measuring the power consumption of a
development board during boot using a power monitor such as TI INA226
and power-cycling the board remotely using a TPS229* power switch.

Add an iio driver for simple GPIO power switches and expose a sysfs
attribute allowing to toggle their state.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 drivers/iio/Kconfig                  |   1 +
 drivers/iio/Makefile                 |   1 +
 drivers/iio/misc/Kconfig             |  17 +++++
 drivers/iio/misc/Makefile            |   6 ++
 drivers/iio/misc/gpio-power-switch.c | 127 +++++++++++++++++++++++++++++++++++
 5 files changed, 152 insertions(+)
 create mode 100644 drivers/iio/misc/Kconfig
 create mode 100644 drivers/iio/misc/Makefile
 create mode 100644 drivers/iio/misc/gpio-power-switch.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2e896e0 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig"
 source "drivers/iio/health/Kconfig"
 source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
+source "drivers/iio/misc/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..4008d5a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -25,6 +25,7 @@ obj-y += frequency/
 obj-y += health/
 obj-y += humidity/
 obj-y += imu/
+obj-y += misc/
 obj-y += light/
 obj-y += magnetometer/
 obj-y += orientation/
diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig
new file mode 100644
index 0000000..8d73751
--- /dev/null
+++ b/drivers/iio/misc/Kconfig
@@ -0,0 +1,17 @@
+#
+# Miscellaneous iio drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Miscellaneous iio drivers"
+
+config GPIO_POWER_SWITCH
+	tristate "GPIO power switch driver"
+	depends on GPIOLIB
+	help
+	  Say yes here to build support for gpio power switches.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called gpio-power-switch.
+
+endmenu
diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile
new file mode 100644
index 0000000..cebd0c4
--- /dev/null
+++ b/drivers/iio/misc/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO misc drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_GPIO_POWER_SWITCH) += gpio-power-switch.o
diff --git a/drivers/iio/misc/gpio-power-switch.c b/drivers/iio/misc/gpio-power-switch.c
new file mode 100644
index 0000000..25fbeb7
--- /dev/null
+++ b/drivers/iio/misc/gpio-power-switch.c
@@ -0,0 +1,127 @@
+/*
+ * GPIO power switch driver using the industrial IO framework.
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/gpio/consumer.h>
+
+struct gpio_pwrsw_context {
+	struct gpio_desc *gpio;
+};
+
+static ssize_t gpio_pwrsw_enable_show(struct device *dev,
+				      struct device_attribute *attr,
+				      char *buf)
+{
+	struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+	int val;
+
+	val = gpiod_get_value_cansleep(ctx->gpio);
+	if (val < 0)
+		return val;
+
+	return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t gpio_pwrsw_enable_store(struct device *dev,
+				       struct device_attribute *attr,
+				       const char *buf, size_t len)
+{
+	struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+	bool val;
+	int ret;
+
+	ret = strtobool(buf, &val);
+	if (ret)
+		return ret;
+
+	gpiod_set_value_cansleep(ctx->gpio, val ? 1 : 0);
+
+	return len;
+}
+
+static IIO_DEVICE_ATTR(in_active, 0644,
+		       gpio_pwrsw_enable_show,
+		       gpio_pwrsw_enable_store, 0);
+
+static struct attribute *gpio_pwrsw_attributes[] = {
+	&iio_dev_attr_in_active.dev_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group gpio_pwrsw_attribute_group = {
+	.attrs = gpio_pwrsw_attributes,
+};
+
+static const struct iio_info gpio_pwrsw_info = {
+	.driver_module = THIS_MODULE,
+	.attrs = &gpio_pwrsw_attribute_group,
+};
+
+static int gpio_pwrsw_probe(struct platform_device *pdev)
+{
+	struct gpio_pwrsw_context *ctx;
+	struct iio_dev *iio_dev;
+	const char *name = NULL;
+	struct device *dev;
+	bool init_state;
+	int gpio_flags;
+
+	dev = &pdev->dev;
+
+	iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx));
+	if (!iio_dev)
+		return -ENOMEM;
+
+	ctx = iio_priv(iio_dev);
+
+	init_state = of_property_read_bool(dev->of_node, "power-switch-on");
+	gpio_flags = init_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+
+	ctx->gpio = devm_gpiod_get(dev, "power", gpio_flags);
+	if (IS_ERR(ctx->gpio)) {
+		dev_err(dev, "unable to get the power switch gpio: %ld\n",
+			PTR_ERR(ctx->gpio));
+		return PTR_ERR(ctx->gpio);
+	}
+
+	of_property_read_string(dev->of_node, "power-switch-name", &name);
+
+	iio_dev->dev.parent = dev;
+	iio_dev->dev.of_node = dev->of_node;
+	iio_dev->name = name ? name : dev->driver->name;
+	iio_dev->info = &gpio_pwrsw_info;
+
+	return devm_iio_device_register(dev, iio_dev);
+}
+
+static const struct of_device_id gpio_pwrsw_of_match[] = {
+	{ .compatible = "gpio-power-switch", },
+	{ },
+};
+
+static struct platform_driver gpio_pwrsw_platform_driver = {
+	.probe = gpio_pwrsw_probe,
+	.driver = {
+		.name = "gpio-power-switch",
+		.of_match_table = gpio_pwrsw_of_match,
+	},
+};
+module_platform_driver(gpio_pwrsw_platform_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("GPIO power switch driver for iio");
+MODULE_LICENSE("GPL v2");
-- 
2.9.3


^ permalink raw reply related

* [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Bartosz Golaszewski @ 2016-12-11 22:21 UTC (permalink / raw)
  To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Rob Herring, Mark Rutland
  Cc: linux-iio, devicetree, linux-kernel, Kevin Hilman,
	Patrick Titiano, Neil Armstrong, Linus Walleij, Alexandre Courbot,
	linux-gpio, Sebastian Reichel, linux-pm, Mark Brown,
	Liam Girdwood, Bartosz Golaszewski
In-Reply-To: <1481494905-18037-1-git-send-email-bgolaszewski@baylibre.com>

Some boards are equipped with simple, GPIO-driven power load switches.
An example of such ICs is the TI tps229* series.

Add device tree bindings allowing to describe them.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 .../bindings/power/gpio-power-switch.txt           | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/gpio-power-switch.txt

diff --git a/Documentation/devicetree/bindings/power/gpio-power-switch.txt b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
new file mode 100644
index 0000000..21420ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
@@ -0,0 +1,25 @@
+GPIO Power Switch
+-----------------
+
+This is the device tree binding for simple, GPIO-driven power load switches
+that do not have any control signals.
+
+Required properties:
+
+- compatible:           must be "gpio-power-switch"
+- power-gpios:          phandle for the GPIO driving the power load switch
+
+Optional properties:
+
+- power-switch-name:    the name of the power switch
+- power-switch-on:      the power switch GPIO is driven high by default
+
+Example
+-------
+
+acme_probe0_power_switch: gpio_power_switch@0 {
+	compatible = "gpio-power-switch";
+	power-switch-name = "acme_probe0_switch";
+	power-gpios = <&pca9535 1 GPIO_ACTIVE_HIGH>;
+	power-switch-on;
+};
-- 
2.9.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox