* Re: [PATCH 3/6] pinctrl: sh-pfc: r8a77990: Add bias pinconf support
From: Geert Uytterhoeven @ 2018-05-14 20:13 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Laurent Pinchart, Geert Uytterhoeven, Linus Walleij, Rob Herring,
Mark Rutland, Linux-Renesas, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Takeshi Kihara
In-Reply-To: <1526008947-26667-4-git-send-email-yoshihiro.shimoda.uh@renesas.com>
Hi Shimoda-san,
On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> This patch implements control of pull-up and pull-down. On this SoC there
> is no simple mapping of GP pins to bias register bits, so we need a table.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Thanks for your patch!
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> @@ -1227,10 +1248,55 @@ enum {
>
> PINMUX_IPSR_GPSR(IP15_31_28, USB30_OVC),
> PINMUX_IPSR_MSEL(IP15_31_28, USB0_OVC_A, SEL_USB_20_CH0_0),
> +
> +/*
> + * Static pins can not be muxed between different functions but
> + * still needs a mark entry in the pinmux list. Add each static
need mark entries
> + * pin to the list without an associated function. The sh-pfc
> + * core will do the right thing and skip trying to mux then pin
mux the pin
> + * while still applying configuration to it
period
I have just sent a patch to fix the other copies, in the hope these grammar
atrocities will stop spreading ;-)
> @@ -1708,8 +1774,263 @@ enum {
> { },
> };
>
> +static const struct pinmux_bias_reg pinmux_bias_regs[] = {
The register definitions look OK to me.
I'll review the actual pin mappings later.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Pavel Machek @ 2018-05-14 20:16 UTC (permalink / raw)
To: Dan Murphy
Cc: Jacek Anaszewski, robh+dt, mark.rutland, afd, devicetree,
linux-kernel, linux-leds
In-Reply-To: <4a631a8e-18ba-0886-039e-004980ae0cc3@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Mon 2018-05-14 15:13:34, Dan Murphy wrote:
> Pavel
>
> On 05/14/2018 03:05 PM, Pavel Machek wrote:
> > Hi!
> >
> >>> OK.
> >>
> >> OK I looked at the max776973 driver and well if the flash-max-microamp and
> >> flash-max-timeout-us nodes are missing it sets a default value for each if the
> >> node is not present.
> >>
> >> So should we remove this code from the Max77693 driver too and fail probe as being asked
> >> in this driver?
> >
> > Well, modifying driver without access to the hardware is tricky
> > :-(. If it does something stupid (like using other than minimum values
> > for the flash-max-microamp/flash-max-timeout-us), it needs to be
> > fixed.
>
> Well we should be able to test the probe/parse dt node and reject the probe if the node is not
> present. That can be done without HW the setup is done pretty early in the probe without even attempting to communicate
> with the hardware.
>
Well, yes, you can do that.
But if someone is actively using board with DT w/o flash-max-microamp,
you'll make them unhappy.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: document Renesas V3HSK board bindings
From: Geert Uytterhoeven @ 2018-05-14 20:28 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Simon Horman, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Mark Rutland
In-Reply-To: <24039c74-d6d3-cac3-6c68-5dcd88ef8ecc@cogentembedded.com>
On Thu, May 10, 2018 at 8:09 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Document the V3H Starter Kit device tree bindings, listing it as
> a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to
> the V3HSK board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp
From: Enric Balletbo Serra @ 2018-05-14 20:30 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree@vger.kernel.org, David Airlie, Brian Norris,
Doug Anderson, linux-kernel, open list:ARM/Rockchip SoC...,
Rob Herring, dri-devel, Chris Zhong, daniel.vetter, Linux ARM
In-Reply-To: <1526291635-31122-1-git-send-email-hl@rock-chips.com>
Hi Lin,
2018-05-14 11:53 GMT+02:00 Lin Huang <hl@rock-chips.com>:
> From: Chris Zhong <zyw@rock-chips.com>
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> Reviewed-by: Enric Balletbo <eballetbo@gmail.com>
If you need to send another version, could you use the following name
and email address instead?
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Thanks :)
Enric
> ---
> Changes in v2:
> - update patch following Enric suggest
> - None
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++++++++++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++-
> 4 files changed, 122 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> - ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
> - if (ret)
> + ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
> + if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> - ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> - DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
> + sizeof(dp->dpcd));
> + if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> - if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> - DP_LINK_STATUS_SIZE)) {
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> + struct drm_dp_aux_msg *msg)
> +{
> + struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
> + int ret;
> + u8 status;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + status = cdn_dp_get_aux_status(dp);
> + if (status == AUX_STATUS_ACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> + else if (status == AUX_STATUS_NACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> + else if (status == AUX_STATUS_DEFER)
> + msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> + return ret;
> +}
> +
> static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(&dp->aux);
> + if (ret)
> + return ret;
>
> INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct platform_device *audio_pdev;
> struct work_struct event_work;
> struct edid *edid;
> + struct drm_dp_aux aux;
>
> struct mutex lock;
> bool connected;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index eb3042c..979355d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
> sizeof(field), field);
> }
>
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> +/*
> + * Returns the number of bytes transferred on success, or a negative
> + * error code on failure. -ETIMEDOUT is returned if mailbox message was
> + * not send successfully;
> + */
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> u8 msg[5], reg[5];
> int ret;
> @@ -247,24 +252,41 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> goto err_dpcd_read;
>
> ret = cdn_dp_mailbox_read_receive(dp, data, len);
> + if (!ret)
> + return len;
>
> err_dpcd_read:
> + DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
> return ret;
> }
>
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> +#define CDN_AUX_HEADER_SIZE 5
> +#define CDN_AUX_MSG_SIZE 20
> +/*
> + * Returns the number of bytes transferred on success, or a negative error
> + * code on failure. -ETIMEDOUT is returned if mailbox message was not send
> + * success; -EINVAL is returned if get the wrong data size after message
> + * is sent
> + */
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> - u8 msg[6], reg[5];
> + u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
> + u8 reg[CDN_AUX_HEADER_SIZE];
> int ret;
>
> - msg[0] = 0;
> - msg[1] = 1;
> + if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
> + return -EINVAL;
> +
> + msg[0] = (len >> 8) & 0xff;
> + msg[1] = len & 0xff;
> msg[2] = (addr >> 16) & 0xff;
> msg[3] = (addr >> 8) & 0xff;
> msg[4] = addr & 0xff;
> - msg[5] = value;
> +
> + memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
> +
> ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
> - sizeof(msg), msg);
> + CDN_AUX_HEADER_SIZE + len, msg);
> if (ret)
> goto err_dpcd_write;
>
> @@ -277,8 +299,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> if (ret)
> goto err_dpcd_write;
>
> - if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
> + if ((len != (reg[0] << 8 | reg[1])) ||
> + (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
> ret = -EINVAL;
> + } else {
> + return len;
> + }
>
> err_dpcd_write:
> if (ret)
> @@ -286,6 +312,33 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> return ret;
> }
>
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
> +{
> + u8 status;
> + int ret;
> +
> + ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS, 0, NULL);
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS,
> + sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + return status;
> +
> +err_get_hpd:
> + DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
> + return ret;
> +}
> +
> int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
> u32 i_size, const u32 *d_mem, u32 d_size)
> {
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index c4bbb4a83..6580b11 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -328,6 +328,13 @@
> #define GENERAL_BUS_SETTINGS 0x03
> #define GENERAL_TEST_ACCESS 0x04
>
> +/* AUX status*/
> +#define AUX_STATUS_ACK 0
> +#define AUX_STATUS_NACK 1
> +#define AUX_STATUS_DEFER 2
> +#define AUX_STATUS_SINK_ERROR 3
> +#define AUX_STATUS_BUS_ERROR 4
> +
> #define DPTX_SET_POWER_MNG 0x00
> #define DPTX_SET_HOST_CAPABILITIES 0x01
> #define DPTX_GET_EDID 0x02
> @@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
> int cdn_dp_event_config(struct cdn_dp_device *dp);
> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
> int cdn_dp_get_edid_block(void *dp, u8 *edid,
> unsigned int block, size_t length);
> int cdn_dp_train_link(struct cdn_dp_device *dp);
> --
> 2.7.4
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Dan Murphy @ 2018-05-14 20:31 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, robh+dt, mark.rutland, afd, devicetree,
linux-kernel, linux-leds
In-Reply-To: <20180514201631.GC3276@amd>
On 05/14/2018 03:16 PM, Pavel Machek wrote:
> On Mon 2018-05-14 15:13:34, Dan Murphy wrote:
>> Pavel
>>
>> On 05/14/2018 03:05 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> OK.
>>>>
>>>> OK I looked at the max776973 driver and well if the flash-max-microamp and
>>>> flash-max-timeout-us nodes are missing it sets a default value for each if the
>>>> node is not present.
>>>>
>>>> So should we remove this code from the Max77693 driver too and fail probe as being asked
>>>> in this driver?
>>>
>>> Well, modifying driver without access to the hardware is tricky
>>> :-(. If it does something stupid (like using other than minimum values
>>> for the flash-max-microamp/flash-max-timeout-us), it needs to be
>>> fixed.
>>
>> Well we should be able to test the probe/parse dt node and reject the probe if the node is not
>> present. That can be done without HW the setup is done pretty early in the probe without even attempting to communicate
>> with the hardware.
>>
>
> Well, yes, you can do that.
>
> But if someone is actively using board with DT w/o flash-max-microamp,
> you'll make them unhappy.
>
I grepped the dt directories and I did not find any upstream dt files configuring the max77693
with a flash led source. Unless Jacek can point out an upstream file I may have over looked.
Unhappiness will come from not upstreaming your code ;)
Dan
> Best regards,
> Pavel
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: Draak: Enable HDMI input and VIN4
From: Geert Uytterhoeven @ 2018-05-14 20:33 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Niklas Söderlund, Laurent Pinchart, Simon Horman,
Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List
In-Reply-To: <1526032802-14376-1-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Fri, May 11, 2018 at 11:59 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> this series enables HDMI input and VIN4 on R-Car D3 Draak board.
>
> The Draak board has an HDMI input connected to an HDMI decoder that feeds
> the VIN capture interface through its parallel video interface.
>
> The series requires the just sent:
> [PATCH 0/5] rcar-vin: Add support for digital input on Gen3
>
> and enables image capture operations on D3 Draak board.
>
> The series has been developed on top of media-master tree but applies cleanly
> on top of latest renesas-driver.
>
> Geert: would you like a topic branch for this series to be included in
> renesas-drivers?
It seems patch 2 has been applied by Simon already, but there is some
discussion pending on patch 3?
> Patches for testing are available at:
> git://jmondi.org/linux d3/media-master/driver
> git://jmondi.org/linux d3/media-master/dts
> git://jmondi.org/linux d3/media-master/test
> git://jmondi.org/vin-tests d3
>
> Thanks
> j
>
> Jacopo Mondi (3):
> dt-bindings: media: rcar-vin: Add R8A77995 support
> arm64: dts: renesas: r8a77995: Add VIN4
> arm64: dts: renesas: draak: Describe HDMI input
>
> .../devicetree/bindings/media/rcar_vin.txt | 1 +
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 ++++
> 3 files changed, 80 insertions(+)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Paul Kocialkowski @ 2018-05-14 20:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Mark Rutland,
Chen-Yu Tsai, Thierry Reding, David Airlie
In-Reply-To: <20180511143647.ici2bfoeeldto3ju@flea>
[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]
Hi and thanks for the review!
Le vendredi 11 mai 2018 à 16:36 +0200, Maxime Ripard a écrit :
> On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,297 @@
> > +/*
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> This really should be the first line, and with a C++ style comment, as
> in:
>
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
> * Copyright (C) ...
>
> See Documentation/process/license-rules.rst
Okay, will do in v5.
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > + brightness-levels = < 0 1 1 1 1 2 2 2
> > + 2 3 3 3 3 4 4 4
> > + 5 5 5 6 6 6 7 7
> > + 8 8 8 9 9 9 10 10
> > + 10 11 11 12 12 12 13 13
> > + 14 14 14 15 15 16 16 17
> > + 17 17 18 18 19 19 20 20
> > + 21 21 21 22 22 23 23 24
> > + 24 25 25 26 26 27 27 28
> > + 28 29 30 30 31 31 32 32
> > + 33 33 34 35 35 36 36 37
> > + 38 38 39 39 40 41 41 42
> > + 43 43 44 44 45 46 47 47
> > + 48 49 49 50 51 51 52 53
> > + 54 54 55 56 57 57 58 59
> > + 60 61 61 62 63 64 65 65
> > + 66 67 68 69 70 71 71 72
> > + 73 74 75 76 77 78 79 80
> > + 81 82 83 84 85 86 87 88
> > + 89 90 91 92 93 94 95 96
> > + 97 98 99 101 102 103 104 105
> > + 106 108 109 110 111 112 114 115
> > + 116 117 119 120 121 123 124 125
> > + 127 128 129 131 132 133 135 136
> > + 138 139 141 142 144 145 147 148
> > + 150 151 153 154 156 157 159 161
> > + 162 164 166 167 169 171 173 174
> > + 176 178 180 181 183 185 187 189
> > + 191 192 194 196 198 200 202 204
> > + 206 208 210 212 214 216 219 221
> > + 223 225 227 229 232 234 236 238
> > + 241 242 244 246 248 250 253 255>;
>
> You kind of overdid it here :)
>
> What I meant to say before was that if you have 10 elements (and you
> really should have something in that magnitude) each step should
> increase the perceived brightness by 10%.
Mhh I think 10 elements would fall too short to really depict the curve
with appropriate precision. Given the usual size for brightness cursors
in e.g. gnome-shell, it feels like a bigger number would be more
appropriate. Let's make it to 100 with values from 0 to 255!
> In this particular case, I really think having something close to <0 4
> 8 16 32 64 128 255> would be enough.
>
> And in general, that kind of odd looking table without any more
> context is just screaming for a comment :)
Noted, I will explain the idea, but probably without the exact formula
that's really a nasty hack written down on a piece of paper sitting in
my garbage at this point.
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Paul Kocialkowski @ 2018-05-14 20:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Mark Rutland,
Chen-Yu Tsai, Thierry Reding, David Airlie
In-Reply-To: <20180511085938.wjmdsdjfvdxd4shk@flea>
[-- Attachment #1: Type: text/plain, Size: 4970 bytes --]
Hi,
Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > as found on the Ainol AW1 tablet.
> > > >
> > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > the two extra lanes per component are grounded.
> > > >
> > > > In the future, it might become necessary to introduce a dedicated
> > > > device-tree property to specify the bus format to use instead of the
> > > > default one for the panel. This will allow supporting different bus
> > > > formats for the same panel modes.
> > > >
> > > > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> > > > ---
> > > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> > > > 1 file changed, 26 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
> > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > > };
> > > >
> > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > + .clock = 40000,
> > > > + .hdisplay = 800,
> > > > + .hsync_start = 800 + 112,
> > > > + .hsync_end = 800 + 112 + 1,
> > > > + .htotal = 800 + 112 + 1 + 87,
> > > > + .vdisplay = 480,
> > > > + .vsync_start = 480 + 141,
> > > > + .vsync_end = 480 + 141 + 1,
> > > > + .vtotal = 480 + 141 + 1 + 38,
> > > > + .vrefresh = 60,
> > > > +};
> > > > +
> > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > + .modes = &innolux_at070tn90_mode,
> > > > + .num_modes = 1,
> > > > + .size = {
> > > > + .width = 154,
> > > > + .height = 86,
> > > > + },
> > > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > +};
> > > > +
> > >
> > > I'm not really convinced this is the right approach. You said it
> > > yourself, the panel is using a 24-bits interface, and you just happen
> > > to have a tablet that routed it using a 18-bits interface instead.
> > >
> > > That doesn't belong in the driver, especially associated to the
> > > compatible, but where the routing is described: in the device
> > > tree. And given that the panel interface is a 24 bits panel, if we
> > > were to have a default, we should have this one, and not the one
> > > fitting your use case.
> >
> > I fully agree, this is why I suggested introducing a dedicated dt
> > property for selecting the bus format (in the commit message). I still
> > proposed this patch as a temporary solution, but I'm definitely willing
> > to craft a proper solution as well.
> >
> > Here is an initial proposition:
> > 1. Making bus_format an array in struct panel_desc and listing all the
> > relevant bus formats that the panel can support there;
>
> I'm not sure this is needed, the input format is always the same in
> your case, the panel will always take a 24 bits RGB value. What you
> want to change is the encoder output format (and I guess you want that
> to be meaningful to enable or not the dithering).
Isn't the panel format supposed to match what the encoder's output
should be aiming for? In my case, that would be RGB666, so the idea
would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
panel. This way, both my setup and RGB888 setups can be supported.
> > 2. Introducing an optional "bus-format" dt property that indicates which
> > bus format to use, and using the first index of the bus formats array if
> > the property is not present;
>
> I guess the width would be enough, and that way we can take the
> bus-width format that is already defined (but used in the v4l2
> framework, not in DRM yet).
Well, we already have bus-format defines on the DRM side and it feels
like mapping these directly in device-tree would be more useful as a
description of the hardware than just having the bus width.
Cheers,
Paul
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
From: Jacek Anaszewski @ 2018-05-14 20:48 UTC (permalink / raw)
To: Dan Murphy, Pavel Machek
Cc: robh+dt, mark.rutland, afd, devicetree, linux-kernel, linux-leds
In-Reply-To: <7d399662-9806-7bb2-e27f-de66557d043c@ti.com>
Dan,
On 05/14/2018 10:07 PM, Dan Murphy wrote:
> Jacek
>
> On 05/11/2018 03:27 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 05/11/2018 02:12 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> Thanks for the review
>>>
>>> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
>>>> Hi Dan,
>>>>
>>>> On 05/10/2018 09:10 PM, Dan Murphy wrote:
>>>>> On 05/10/2018 02:06 PM, Dan Murphy wrote:
>>>>>> Pavel
>>>>>>
>>>>>> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>>> Introduce the device tree bindings for the lm3601x
>>>>>>>> family of LED torch, flash and IR drivers.
>>>>>>>>
>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>>>
>>>>>>> Better, thanks.
>>>>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>>>>>>> @@ -0,0 +1,50 @@
>>>>>>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>>>>>>
>>>>>>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>>>>>>> the same time?
>>>>>>
>>>>>> It is a single LED driver. It can drive a Torch white LED or IR LED indefinitely or if the driver
>>>>>> is programmed to strobe mode the driver will drive the configured LED for the flash timeout specified.
>>>>>>
>>>>>> Basically a flash and a flash light. IR or White LED.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +led-controller@64 {
>>>>>>>> + compatible = "ti,lm36010";
>>>>>>>> + #address-cells = <1>;
>>>>>>>> + #size-cells = <0>;
>>>>>>>> + reg = <0x64>;
>>>>>>>> +
>>>>>>>> + led@0 {
>>>>>>>> + reg = <0>;
>>>>>>>> + label = "white:torch";
>>>>>>>> + led-max-microamp = <10000>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + led@1 {
>>>>>>>> + reg = <1>;
>>>>>>>> + label = "white:flash";
>>>>>>>> + flash-max-microamp = <10000>;
>>>>>>>> + flash-max-timeout-us = <800>;
>>>>>>>> + };
>>>>>>>
>>>>>>> Is this realistic config? I'd expect flash to use more power than
>>>>>>> torch, and would expect longer timeout than 0.8msec.
>>>>>>
>>>>>> Timeout in the spreadsheet is ms I will update this example and code
>>>>>> Current in the spreadsheet is mA I will update this example and code
>>>>>>
>>>>>>>
>>>>>>> Also.. if this is physically one white LED, it should not be
>>>>>>> spread over reg = <0> and reg = <1>...
>>>>>>
>>>>>> If the torch LED and strobe LED are the same LED how do I expose them both to the user.
>>>>>> It is up to consumer to configure the required interfaces they want to expose to the filesystem.
>>>>
>>>> LED flash class interface is prepared for it.
>>>> led_clasdev_flash_register() internally calls led_classdev_register(),
>>>> so there is brightness file available for torch related operations.
>>>
>>> Yes the flash class may handle this and expose the brightness node but the HW has two different registers to set the
>>> corresponding brightness so one set brightness node does not work.
>>> There is no way to differentiate between the strobe brightness (register 4) and the torch brightness (register 3).
>>
>> Hmm? There is brightness file (with brightness_set{_blocking} op) from
>> LED class and flash_brightness file (with flash_brightness_set op) from
>> LED class flash.
>>
>> I've only now realized that you're not using flash_brightness_set op for
>> the "strobe_node" in your driver. I assume that you overlooked it.
>> Please don't introduce "strobe_brightness" naming convention - we
>> already have "flash_brightness" for that.
>>
>>> When the enable register is written the driver will read the corresponding register and set
>>> the current for the LED.
>>>
>>> This is why I separated out the strobe from the torch into 2 different LED nodes.
>>>
>>> I cannot seem to find the data sheet on line for the max77693 so I cannot verify that the device only has
>>> a single brightness register for both torch and strobe.
>>
>> It wasn't openly available at least at the time when I had an access
>> to it.
>>
>> But - please look at the functions max77693_set_torch_current() and
>> max77693_set_flash_current(). The device has separate registers
>> for torch and flash brightnesses.
>
>
> I have looked at these functions and the parse dt function that dictates if there is 1 fled or 2 fled.
> I am having trouble associating what these mean because the led-sources is being used to define how many LEDs.
>
> In the common.txt it says
> "- led-sources : List of device current outputs the LED is connected to. The
> outputs are identified by the numbers that must be defined
> in the LED device binding documentation."
>
> I cannot find the max77693 dt documentation or even a dt file that defines what the led-sources could be defined as.
> In addition, per the common.txt, the led sources should define the current outputs the LED is connected to.
You can find more details in
Documentation/devicetree/bindings/mfd/max77693.txt.
Generally the led-sources property was introduced to solve this
particular case when there are two IOUTS that can have connected
two LEDs or a single LED which allows to feed it with greater current.
>
> Is one to assume that it is referring to the physical current pin connection or the devices internal current routing?
>
> When I first referenced this driver as template driver it was misleading to say fled1 and fled2 as I took it to mean, and I still do, that the
> driver supports 2 LED connections and not a single output pin with different internal current routing.
>
> Without the data sheet or the dt documentation it makes understanding a little difficult.
There are more straightforward LED flash class drivers, e.g.
drivers/leds/leds-aat1290, you can refer to.
> I will fix it up how ever you would like it to be but I am thinking we need to fix up the max77693 as well so we can have 2 reference
> drivers.
There is also drivers/leds/leds-as3645a.c and one greybus driver.
So we have in fact four LED flash class drivers in the tree :-)
> It is very difficult to derive the driver without a public version of the data sheet.
I agree, but mfd documentation I pointed should be enough to
increase your comprehension of the subject, I hope. If not, then
we can extend it basing on your remarks and my memory.
>>>>>> Maybe they don't want the strobe feature and just want LED on/off and switch between IR and White.
>>>>>>
>>>>>> The IR is driven via a different output pin.
>>>>>
>>>>> Correction. There is only one LED drive pin. The mode selected determines how the device will drive the
>>>>> LED. So you may have one device to drive a Torch and another device to drive the LED.
>>>>
>>>> But only one type of LED can be soldered on the board at a time, right?
>>>> If yes, then this is clearly a DT related configuration, and only
>>>> one child DT node should be defined for given board.
>>>
>>> But see above. There is not a clean way to expose the torch/ir and strobe separately.
>>>
>>> Dan
>>>
>>>
>>>>
>>>>> Strobe is available in either case but not always required if strobe is not desired by the customer hence
>>>>> why I have a separate DT node for it.
>>>>>
>>>>> Dan
>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Pavel
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 0/4] Meson8m2 (32-bit ARM) SoC support
From: Martin Blumenstingl @ 2018-05-14 20:55 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-amlogic, carlo, devicetree, balbes-150
In-Reply-To: <7h603v115k.fsf@baylibre.com>
On Fri, May 11, 2018 at 2:33 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> This series adds support for the Meson8m2 SoC. This SoC is mostly
>> compatible with Meson8 while using some peripherals from Meson8b. Patch
>> #4 contains a list of (known) differences between the Meson8 and Meson8m2
>> SoCs.
>>
>> The first supported board with Meson8m2 SoC is the "Tronsmart MXIII Plus"
>> where Oleg contributed the initial .dts and heavily tested it (many
>> thanks!). His testing also confirmed that the Meson8m2 SoC uses the same
>> register layout for the Ethernet "glue registers (supported by the
>> dwmac-meson8b driver) as Meson8b.
>>
>> changes since v1 at [0]:
>> - do not create a new MACH_MESON8M2 Kconfig entry as suggested by Kevin
>> (MACH_MESON8 is re-used instead). This affects patch #1 (which was
>> patch #3 in v1) and patch #4 (which was patch #6 in v1)
>> - dropped patches #1 and #2 from v1 because Kevin already applied these
>> ("dt-bindings: arm: amlogic: add support for the Meson8m2 SoC" and
>> "dt-bindings: arm: amlogic: add support for the Tronsmart MXIII Plus")
>
> Applied to v4.18/dt.
thank you!
> One more request: Could you send one more patch (on top of my v4.18/dt)
> that gets rid of the Kconfig for the 8B also?
I put that on my TODO-list, I'll send a patch before my next batch of
32-bit dt updates
Regards
Martin
^ permalink raw reply
* Re: [PATCH v4 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver
From: Jacek Anaszewski @ 2018-05-14 21:01 UTC (permalink / raw)
To: Baolin Wang, pavel, robh+dt, mark.rutland
Cc: xiaotong.lu, broonie, linux-leds, devicetree, linux-kernel
In-Reply-To: <f20d9b010a256b695dbaefedacdf3d29fd4b9674.1526279287.git.baolin.wang@linaro.org>
Hi Baolin,
Thanks for the updated patch set.
On 05/14/2018 08:34 AM, Baolin Wang wrote:
> This patch adds Spreadtrum SC27xx PMIC series breathing light controller
> driver, which can support 3 LEDs. Each LED can work at normal PWM mode
> and breathing mode.
>
> Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> Changes since v3:
> - Remove the breathing mode support, and will add in future with
> common interfaces.
>
> Changes since v2:
> - Add more description for the sysfs nodes.
> - Change the sysfs nodes to RW.
> - Reset the time values to 0 when disable the LED.
> - Remove 'value' from 'struct sc27xx_led'.
> - Add 'remove' interface to destroy mutex.
> - Remove max_brightness setting when initializing the LED.
> - Other coding style fixes.
>
> Changes since v1:
> - Add ABI documentation.
> - Add mutex protection in case of concurrent access.
> - Change the LED device name pattern.
> - Fix build warning.
> ---
> drivers/leds/Kconfig | 11 ++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-sc27xx-bltc.c | 244 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 256 insertions(+)
> create mode 100644 drivers/leds/leds-sc27xx-bltc.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 2c896c0..319449b 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -647,6 +647,17 @@ config LEDS_IS31FL32XX
> LED controllers. They are I2C devices with multiple constant-current
> channels, each with independent 256-level PWM control.
>
> +config LEDS_SC27XX_BLTC
> + tristate "LED support for the SC27xx breathing light controller"
> + depends on LEDS_CLASS && MFD_SC27XX_PMIC
> + depends on OF
> + help
> + Say Y here to include support for the SC27xx breathing light controller
> + LEDs.
> +
> + This driver can also be built as a module. If so the module will be
> + called leds-sc27xx-bltc.
> +
> comment "LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)"
>
> config LEDS_BLINKM
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 91eca81..ff6917e 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
> +obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
>
> # LED SPI Drivers
> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
> new file mode 100644
> index 0000000..54a90c8
> --- /dev/null
> +++ b/drivers/leds/leds-sc27xx-bltc.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Spreadtrum Communications Inc.
> +
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <uapi/linux/uleds.h>
> +
> +/* PMIC global control register definition */
> +#define SC27XX_MODULE_EN0 0xc08
> +#define SC27XX_CLK_EN0 0xc18
> +#define SC27XX_RGB_CTRL 0xebc
> +
> +#define SC27XX_BLTC_EN BIT(9)
> +#define SC27XX_RTC_EN BIT(7)
> +#define SC27XX_RGB_PD BIT(0)
> +
> +/* Breathing light controller register definition */
> +#define SC27XX_LEDS_CTRL 0x00
> +#define SC27XX_LEDS_PRESCALE 0x04
> +#define SC27XX_LEDS_DUTY 0x08
> +#define SC27XX_LEDS_CURVE0 0x0c
> +#define SC27XX_LEDS_CURVE1 0x10
> +
> +#define SC27XX_CTRL_SHIFT 4
> +#define SC27XX_LED_RUN BIT(0)
> +#define SC27XX_LED_TYPE BIT(1)
> +
> +#define SC27XX_DUTY_SHIFT 8
> +#define SC27XX_DUTY_MASK GENMASK(15, 0)
> +#define SC27XX_MOD_MASK GENMASK(7, 0)
> +
> +#define SC27XX_LEDS_OFFSET 0x10
> +#define SC27XX_LEDS_MAX 3
> +
> +struct sc27xx_led {
> + char name[LED_MAX_NAME_SIZE];
> + struct led_classdev ldev;
> + struct sc27xx_led_priv *priv;
> + u8 line;
> + bool active;
> +};
> +
> +struct sc27xx_led_priv {
> + struct sc27xx_led leds[SC27XX_LEDS_MAX];
> + struct regmap *regmap;
> + struct mutex lock;
> + u32 base;
> +};
> +
> +#define to_sc27xx_led(ldev) \
> + container_of(ldev, struct sc27xx_led, ldev)
> +
> +static int sc27xx_led_init(struct regmap *regmap)
> +{
> + int err;
> +
> + err = regmap_update_bits(regmap, SC27XX_MODULE_EN0, SC27XX_BLTC_EN,
> + SC27XX_BLTC_EN);
> + if (err)
> + return err;
> +
> + err = regmap_update_bits(regmap, SC27XX_CLK_EN0, SC27XX_RTC_EN,
> + SC27XX_RTC_EN);
> + if (err)
> + return err;
> +
> + return regmap_update_bits(regmap, SC27XX_RGB_CTRL, SC27XX_RGB_PD, 0);
> +}
> +
> +static u32 sc27xx_led_get_offset(struct sc27xx_led *leds)
> +{
> + return leds->priv->base + SC27XX_LEDS_OFFSET * leds->line;
> +}
> +
> +static int sc27xx_led_enable(struct sc27xx_led *leds, enum led_brightness value)
> +{
> + u32 base = sc27xx_led_get_offset(leds);
> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
> + struct regmap *regmap = leds->priv->regmap;
> + int err;
> +
> + err = regmap_update_bits(regmap, base + SC27XX_LEDS_DUTY,
> + SC27XX_DUTY_MASK,
> + (value << SC27XX_DUTY_SHIFT) |
> + SC27XX_MOD_MASK);
> + if (err)
> + return err;
> +
> + return regmap_update_bits(regmap, ctrl_base,
> + (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift,
> + (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift);
> +}
> +
> +static int sc27xx_led_disable(struct sc27xx_led *leds)
> +{
> + struct regmap *regmap = leds->priv->regmap;
> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
> +
> + return regmap_update_bits(regmap, ctrl_base,
> + (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
> +}
> +
> +static int sc27xx_led_set(struct led_classdev *ldev, enum led_brightness value)
> +{
> + struct sc27xx_led *leds = to_sc27xx_led(ldev);
> + int err;
> +
> + mutex_lock(&leds->priv->lock);
> +
> + if (value == LED_OFF)
> + err = sc27xx_led_disable(leds);
> + else
> + err = sc27xx_led_enable(leds, value);
> +
> + mutex_unlock(&leds->priv->lock);
> +
> + return err;
> +}
> +
> +static int sc27xx_led_register(struct device *dev, struct sc27xx_led_priv *priv)
> +{
> + int i, err;
> +
> + err = sc27xx_led_init(priv->regmap);
> + if (err)
> + return err;
> +
> + for (i = 0; i < SC27XX_LEDS_MAX; i++) {
> + struct sc27xx_led *led = &priv->leds[i];
> +
> + if (!led->active)
> + continue;
> +
> + led->line = i;
> + led->priv = priv;
> + led->ldev.name = led->name;
> + led->ldev.brightness_set_blocking = sc27xx_led_set;
> +
> + err = devm_led_classdev_register(dev, &led->ldev);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int sc27xx_led_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node, *child;
> + struct sc27xx_led_priv *priv;
> + const char *str;
> + u32 base, count, reg;
> + int err;
> +
> + count = of_get_child_count(np);
> + if (!count || count > SC27XX_LEDS_MAX)
> + return -EINVAL;
> +
> + err = of_property_read_u32(np, "reg", &base);
> + if (err) {
> + dev_err(dev, "fail to get reg of property\n");
> + return err;
> + }
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> + mutex_init(&priv->lock);
> + priv->base = base;
> + priv->regmap = dev_get_regmap(dev->parent, NULL);
> + if (IS_ERR(priv->regmap)) {
> + err = PTR_ERR(priv->regmap);
> + dev_err(dev, "failed to get regmap: %d\n", err);
> + return err;
> + }
> +
> + for_each_child_of_node(np, child) {
> + err = of_property_read_u32(child, "reg", ®);
> + if (err) {
> + of_node_put(child);
> + mutex_destroy(&priv->lock);
> + return err;
> + }
> +
> + if (reg >= SC27XX_LEDS_MAX || priv->leds[reg].active) {
> + of_node_put(child);
> + mutex_destroy(&priv->lock);
> + return -EINVAL;
> + }
> +
> + priv->leds[reg].active = true;
> +
> + err = of_property_read_string(child, "label", &str);
> + if (err)
> + snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> + "sc27xx::");
> + else
> + snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> + "sc27xx:%s", str);
> + }
> +
> + err = sc27xx_led_register(dev, priv);
> + if (err)
> + mutex_destroy(&priv->lock);
> +
> + return err;
> +}
> +
> +static int sc27xx_led_remove(struct platform_device *pdev)
> +{
> + struct sc27xx_led_priv *priv = platform_get_drvdata(pdev);
> +
> + mutex_destroy(&priv->lock);
> + return 0;
> +}
> +
> +static const struct of_device_id sc27xx_led_of_match[] = {
> + { .compatible = "sprd,sc2731-bltc", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sc27xx_led_of_match);
> +
> +static struct platform_driver sc27xx_led_driver = {
> + .driver = {
> + .name = "sprd-bltc",
> + .of_match_table = sc27xx_led_of_match,
> + },
> + .probe = sc27xx_led_probe,
> + .remove = sc27xx_led_remove,
> +};
> +
> +module_platform_driver(sc27xx_led_driver);
> +
> +MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
> +MODULE_AUTHOR("Xiaotong Lu <xiaotong.lu@spreadtrum.com>");
> +MODULE_LICENSE("GPL v2");
>
Patch set applied to the for-next branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [RFC PATCH 00/10] Add support for drm/rockchip to dynamically control the DDR frequency.
From: Enric Balletbo i Serra @ 2018-05-14 21:16 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
Will Deacon, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Sandy Huang, David Airlie
Cc: linux-pm, linux-kernel, Derek Basehore, linux-clk, linux-rockchip,
dri-devel, Lin Huang, kernel, Sean Paul, linux-arm-kernel,
Matthias Kaehlcke, Yakir Yang, Shawn Lin, Catalin Marinas,
Elaine Zhang, Rafael J. Wysocki, Mark Yao, Geert Uytterhoeven,
Kever Yang, Brian Norris, Douglas Anderson
Dear all,
The rk3399 platform has a DFI controller that can monitor DDR load and a
DMC driver that talks with the TF-A (Trusted Firmware-A) to dynamically
set the DDR frequency with following flow.
kernel Trusted Firmware-A
(bl31)
monitor ddr load
|
|
get_target_rate
|
| pass rate to TF-A
clk_set_rate(ddr) --------------------->run ddr dvs flow
|
|
<------------------------------end ddr dvs flow
|
|
return
These patches add support for devfreq to dynamically control the DDR
frequency into the drm rockchip driver. By default it uses the
'simple_ondemand' governor which can adjust the frequency based on the
DDR load.
Although the patches were present in the chromeos kernel for long time I
am sending this as a RFC because I have doubts on some of them,
specially patch 4/10 that tries to sync the TF-A with the kernel using a
mutex, to be honest I did not find another way to do it so feedback is
more than welcome.
The patches apply on top of current 4.17-rc5 and depends on the
following series to apply cleanly.
1. https://lkml.org/lkml/2018/5/9/464
2. https://lkml.org/lkml/2018/4/23/354
Waiting for your feedback.
Best regards,
Enric
Derek Basehore (3):
devfreq: rk3399_dmc / clk: rockchip: Sync with vblank in the kernel
for DDRfreq.
devfreq: rk3399_dmc / clk: rockchip: Disable DDR clk timeout on
suspend.
clk: rockchip: set clk-ddr to GET_RATE_NOCACHE.
Enric Balletbo i Serra (3):
devfreq: rockchip-dfi: Move GRF definitions to a common place.
dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle.
devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Lin Huang (3):
devfreq: rk3399_dmc / rockchip: pm_domains: Register notify to DMC
driver.
arm64: dts: rk3399: Add dfi and dmc nodes.
arm64: dts: rockchip: Enable dmc and dfi nodes on gru.
Sean Paul (1):
drm: rockchip: Add DDR devfreq support.
.../bindings/devfreq/rk3399_dmc.txt | 2 +
.../rockchip/rk3399-dram-default-timing.dtsi | 38 ++++
arch/arm64/boot/dts/rockchip/rk3399-dram.h | 73 +++++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 21 ++
.../boot/dts/rockchip/rk3399-op1-opp.dtsi | 29 +++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 22 +-
drivers/clk/rockchip/clk-ddr.c | 159 ++++++++++++---
drivers/clk/rockchip/clk.c | 2 +-
drivers/clk/rockchip/clk.h | 3 +-
drivers/devfreq/event/rockchip-dfi.c | 23 +--
drivers/devfreq/rk3399_dmc.c | 191 +++++++++++++++---
drivers/devfreq/rk3399_dmc_priv.h | 16 ++
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 46 +++++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 9 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 35 ++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++++
drivers/soc/rockchip/pm_domains.c | 36 ++++
include/soc/rockchip/rk3399_dmc.h | 44 ++++
include/soc/rockchip/rk3399_grf.h | 21 ++
include/soc/rockchip/rockchip_sip.h | 1 +
20 files changed, 734 insertions(+), 71 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram.h
create mode 100644 drivers/devfreq/rk3399_dmc_priv.h
create mode 100644 include/soc/rockchip/rk3399_dmc.h
create mode 100644 include/soc/rockchip/rk3399_grf.h
--
2.17.0
^ permalink raw reply
* [RFC PATCH 02/10] dt-bindings: devfreq: rk3399_dmc: Add rockchip, pmu phandle.
From: Enric Balletbo i Serra @ 2018-05-14 21:16 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
Will Deacon, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Sandy Huang, David Airlie
Cc: Mark Rutland, devicetree, Lin Huang, linux-pm, Derek Basehore,
linux-kernel, dri-devel, linux-rockchip, Sean Paul, kernel,
linux-clk, linux-arm-kernel
In-Reply-To: <20180514211610.26618-1-enric.balletbo@collabora.com>
The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU
general register files to know the DRAM type, so add a phandle to the
syscon that manages these registers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
index 0ec68141f85a..951789c0cdd6 100644
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -12,6 +12,8 @@ Required properties:
for details.
- center-supply: DMC supply node.
- status: Marks the node enabled/disabled.
+- rockchip,pmu: Phandle to the syscon managing the "PMU general register
+ files".
Optional properties:
- interrupts: The CPU interrupt number. The interrupt specifier
--
2.17.0
^ permalink raw reply related
* [RFC PATCH 09/10] arm64: dts: rk3399: Add dfi and dmc nodes.
From: Enric Balletbo i Serra @ 2018-05-14 21:16 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
Will Deacon, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Sandy Huang, David Airlie
Cc: linux-pm, linux-kernel, Derek Basehore, linux-clk, linux-rockchip,
dri-devel, Lin Huang, kernel, Sean Paul, linux-arm-kernel,
Nickey Yang, devicetree, Yakir Yang, Mark Yao, Jacob Chen,
Kever Yang, Brian Norris, Shawn Lin, Douglas Anderson,
Catalin Marinas, Caesar Wang, Mark Rutland
In-Reply-To: <20180514211610.26618-1-enric.balletbo@collabora.com>
From: Lin Huang <hl@rock-chips.com>
These are required to support DDR DVFS on rk3399 platform. The patch also
introduces two new files (rk3399-dram.h and rk3399-dram-default-timing)
with default DRAM settings.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
.../rockchip/rk3399-dram-default-timing.dtsi | 38 ++++++++++
arch/arm64/boot/dts/rockchip/rk3399-dram.h | 73 +++++++++++++++++++
.../boot/dts/rockchip/rk3399-op1-opp.dtsi | 29 ++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 +++++
4 files changed, 160 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram.h
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
new file mode 100644
index 000000000000..4dfe3e1d8bdf
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Lin Huang <hl@rock-chips.com>
+ */
+
+#include "rk3399-dram.h"
+
+rockchip,ddr3_speed_bin = <21>;
+rockchip,pd_idle = <0x40>;
+rockchip,sr_idle = <0x2>;
+rockchip,sr_mc_gate_idle = <0x3>;
+rockchip,srpd_lite_idle = <0x4>;
+rockchip,standby_idle = <0x2000>;
+rockchip,dram_dll_dis_freq = <300000000>;
+rockchip,phy_dll_dis_freq = <125000000>;
+rockchip,auto_pd_dis_freq = <666000000>;
+rockchip,ddr3_odt_dis_freq = <333000000>;
+rockchip,ddr3_drv = <DDR3_DS_40ohm>;
+rockchip,ddr3_odt = <DDR3_ODT_120ohm>;
+rockchip,phy_ddr3_ca_drv = <PHY_DRV_ODT_40>;
+rockchip,phy_ddr3_dq_drv = <PHY_DRV_ODT_40>;
+rockchip,phy_ddr3_odt = <PHY_DRV_ODT_240>;
+rockchip,lpddr3_odt_dis_freq = <333000000>;
+rockchip,lpddr3_drv = <LP3_DS_34ohm>;
+rockchip,lpddr3_odt = <LP3_ODT_240ohm>;
+rockchip,phy_lpddr3_ca_drv = <PHY_DRV_ODT_40>;
+rockchip,phy_lpddr3_dq_drv = <PHY_DRV_ODT_40>;
+rockchip,phy_lpddr3_odt = <PHY_DRV_ODT_240>;
+rockchip,lpddr4_odt_dis_freq = <333000000>;
+rockchip,lpddr4_drv = <LP4_PDDS_60ohm>;
+rockchip,lpddr4_dq_odt = <LP4_DQ_ODT_40ohm>;
+rockchip,lpddr4_ca_odt = <LP4_CA_ODT_40ohm>;
+rockchip,phy_lpddr4_ca_drv = <PHY_DRV_ODT_40>;
+rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>;
+rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>;
+rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-dram.h b/arch/arm64/boot/dts/rockchip/rk3399-dram.h
new file mode 100644
index 000000000000..4b3d4a79923b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-dram.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR X11) */
+/*
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Lin Huang <hl@rock-chips.com>
+ */
+
+#ifndef _DTS_DRAM_ROCKCHIP_RK3399_H
+#define _DTS_DRAM_ROCKCHIP_RK3399_H
+
+#define DDR3_DS_34ohm 34
+#define DDR3_DS_40ohm 40
+
+#define DDR3_ODT_DIS 0
+#define DDR3_ODT_40ohm 40
+#define DDR3_ODT_60ohm 60
+#define DDR3_ODT_120ohm 120
+
+#define LP2_DS_34ohm 34
+#define LP2_DS_40ohm 40
+#define LP2_DS_48ohm 48
+#define LP2_DS_60ohm 60
+#define LP2_DS_68_6ohm 68 /* optional */
+#define LP2_DS_80ohm 80
+#define LP2_DS_120ohm 120 /* optional */
+
+#define LP3_DS_34ohm 34
+#define LP3_DS_40ohm 40
+#define LP3_DS_48ohm 48
+#define LP3_DS_60ohm 60
+#define LP3_DS_80ohm 80
+#define LP3_DS_34D_40U 3440
+#define LP3_DS_40D_48U 4048
+#define LP3_DS_34D_48U 3448
+
+#define LP3_ODT_DIS 0
+#define LP3_ODT_60ohm 60
+#define LP3_ODT_120ohm 120
+#define LP3_ODT_240ohm 240
+
+#define LP4_PDDS_40ohm 40
+#define LP4_PDDS_48ohm 48
+#define LP4_PDDS_60ohm 60
+#define LP4_PDDS_80ohm 80
+#define LP4_PDDS_120ohm 120
+#define LP4_PDDS_240ohm 240
+
+#define LP4_DQ_ODT_40ohm 40
+#define LP4_DQ_ODT_48ohm 48
+#define LP4_DQ_ODT_60ohm 60
+#define LP4_DQ_ODT_80ohm 80
+#define LP4_DQ_ODT_120ohm 120
+#define LP4_DQ_ODT_240ohm 240
+#define LP4_DQ_ODT_DIS 0
+
+#define LP4_CA_ODT_40ohm 40
+#define LP4_CA_ODT_48ohm 48
+#define LP4_CA_ODT_60ohm 60
+#define LP4_CA_ODT_80ohm 80
+#define LP4_CA_ODT_120ohm 120
+#define LP4_CA_ODT_240ohm 240
+#define LP4_CA_ODT_DIS 0
+
+#define PHY_DRV_ODT_Hi_Z 0
+#define PHY_DRV_ODT_240 240
+#define PHY_DRV_ODT_120 120
+#define PHY_DRV_ODT_80 80
+#define PHY_DRV_ODT_60 60
+#define PHY_DRV_ODT_48 48
+#define PHY_DRV_ODT_40 40
+#define PHY_DRV_ODT_34_3 34
+
+#endif /* _DTS_DRAM_ROCKCHIP_RK3399_H */
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index d8a120f945c8..4c634e58425d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -147,6 +147,31 @@
opp-microvolt = <1075000>;
};
};
+
+ dmc_opp_table: dmc_opp_table {
+ compatible = "operating-points-v2";
+
+ opp00 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <900000>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <900000>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <666000000>;
+ opp-microvolt = <900000>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <900000>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <928000000>;
+ opp-microvolt = <900000>;
+ };
+ };
};
&cpu_l0 {
@@ -176,3 +201,7 @@
&gpu {
operating-points-v2 = <&gpu_opp_table>;
};
+
+&dmc {
+ operating-points-v2 = <&dmc_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4550c0f82be9..e012cc8ae3d4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1830,6 +1830,26 @@
status = "disabled";
};
+ dfi: dfi@ff630000 {
+ reg = <0x00 0xff630000 0x00 0x4000>;
+ compatible = "rockchip,rk3399-dfi";
+ rockchip,pmu = <&pmugrf>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru PCLK_DDR_MON>;
+ clock-names = "pclk_ddr_mon";
+ status = "disabled";
+ };
+
+ dmc: dmc {
+ compatible = "rockchip,rk3399-dmc";
+ rockchip,pmu = <&pmugrf>;
+ devfreq-events = <&dfi>;
+ clocks = <&cru SCLK_DDRC>;
+ clock-names = "dmc_clk";
+ #include "rk3399-dram-default-timing.dtsi"
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.17.0
^ permalink raw reply related
* [RFC PATCH 10/10] arm64: dts: rockchip: Enable dmc and dfi nodes on gru.
From: Enric Balletbo i Serra @ 2018-05-14 21:16 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
Will Deacon, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Sandy Huang, David Airlie
Cc: linux-pm, linux-kernel, Derek Basehore, linux-clk, linux-rockchip,
dri-devel, Lin Huang, kernel, Sean Paul, linux-arm-kernel,
Nickey Yang, Yakir Yang, Shawn Lin, Catalin Marinas, Mark Yao,
Jacob Chen, Kever Yang, Brian Norris, Douglas Anderson,
Jeffy Chen, Matthias Kaehlcke, devicetree
In-Reply-To: <20180514211610.26618-1-enric.balletbo@collabora.com>
From: Lin Huang <hl@rock-chips.com>
Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY Interface)
nodes on gru/kevin boards so we can support DDR DVFS.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 21 ++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 18f546f2dfd1..ba2cfdd082b8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -525,6 +525,12 @@
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
+&dmc_opp_table {
+ opp04 {
+ opp-suspend;
+ };
+};
+
/*
* Set some suspend operating points to avoid OVP in suspend
*
@@ -600,6 +606,10 @@
<400000000>;
};
+&display_subsystem {
+ devfreq = <&dmc>;
+};
+
&emmc_phy {
status = "okay";
};
@@ -766,6 +776,17 @@ ap_i2c_audio: &i2c8 {
status = "okay";
};
+&dfi {
+ status = "okay";
+};
+
+&dmc {
+ status = "okay";
+ center-supply = <&ppvar_centerlogic>;
+ upthreshold = <25>;
+ downdifferential = <15>;
+};
+
&sdhci {
/*
* Signal integrity isn't great at 200 MHz and 150 MHz (DDR) gives the
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e012cc8ae3d4..518c742293fc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -160,7 +160,7 @@
};
};
- display-subsystem {
+ display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <&vopl_out>, <&vopb_out>;
};
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 01/12] platform/early: add a new field to struct device
From: Geert Uytterhoeven @ 2018-05-14 21:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-2-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Add a new single-bit field to struct device which will be used to
> indicate that a device was probed early in the boot sequence.
>
> This does not affect the size of struct device on any architecture
> I built on (ARM, ARM64, x86_64).
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 02/12] platform/early: don't WARN() on non-empty devres list for early devices
From: Geert Uytterhoeven @ 2018-05-14 21:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-3-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Early platform devices can have devres objects allocated in
> early_probe(). This is not a bug so don't dump stack in this case.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 03/12] platform/early: export platform_match() locally
From: Geert Uytterhoeven @ 2018-05-14 21:25 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-4-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We will use this function to match devices in the early platform core
> code. Export it locally in drivers/base.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 04/12] platform: provide a separate function for initializing platform devices
From: Geert Uytterhoeven @ 2018-05-14 21:25 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-5-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The early platform driver framework will allocate platform devices
> using its own internal mechanisms. Provide a function that allows to
> initialize a platform device object without allocating it.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 05/12] platform: export platform_device_release() locally
From: Geert Uytterhoeven @ 2018-05-14 21:25 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-6-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The early platform driver mechanism will use this function as the
> device release callback. Make it available in drivers/base.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 06/12] of: add a new flag for OF device nodes
From: Geert Uytterhoeven @ 2018-05-14 21:25 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-7-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This flag indicates that a device node has been populated early and
> that it needs different handling when called from
> of_platform_populate().
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 07/12] of/platform: provide a separate routine for setting up device resources
From: Geert Uytterhoeven @ 2018-05-14 21:26 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-8-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The early platform driver framework will need to setup the device
> resources before the regular populating of the device tree happens.
>
> Provide a separate function for that.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 08/12] of/platform: provide a separate routine for device initialization
From: Geert Uytterhoeven @ 2018-05-14 21:26 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-9-brgl@bgdev.pl>
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The early platform device framework will need to initialize the
> platform device objects without them being allocated in
> of_device_alloc(). Provide a routine that allows it.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 0/6] devfreq: rk3399_dmc: improve rk3399_dmc driver and it's documentation
From: Enric Balletbo i Serra @ 2018-05-14 21:28 UTC (permalink / raw)
To: myungjoo.ham, Kyungmin Park, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org,
heiko@sntech.de, linux-pm@vger.kernel.org, dbasehore@chromium.org,
linux-kernel@vger.kernel.org, dianders@google.com,
groeck@chromium.org, kernel@collabora.com, hl@rock-chips.com,
Chanwoo Choi, Mark Rutland
In-Reply-To: <20180514103218epcms1p487dcebca93bacca64eca1775b2cd826d@epcms1p4>
On 14/05/18 12:32, MyungJoo Ham wrote:
>> Dear all,
>>
>> These patches is an attempt to improve a little bit the rk3399_dmc
>> driver and it's documentation in order to have all in a better shape for
>> a future work I am doing. My final intention is add ddrfreq support for
>> rockchip drm driver, but the patches for this are still
>> work-in-progress. So let's start with this first patchset that is
>> basically some fixes/improvements for the rk3399_dmc driver.
>>
>> The patches apply on top of current 4.17-rc3.
>>
>> Best regards,
>> Enric
>>
>
> Dear Enric,
>
> It appears that this patchset is ready to be applied.
>
> Is "dt-binding" part going to be merged separatedly?
> Or may I handle all the 6 commits? (assuming the three dt-binding got acks from dt maintainers)
>
In my experience (based on other patches I sent for other subsystems) the
dt-bindings goes through the same tree as the other patches. So, ideally, you
should handle all the 6 commits, but this is a question for the DT maintainers I
guess. Maybe Rob or Mark can give us a clue?
Thanks,
Enric
> Cheers,
> MyungJoo
>
>
^ permalink raw reply
* Re: [PATCH 09/12] platform/early: add an init section for early driver data
From: Geert Uytterhoeven @ 2018-05-14 21:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-10-brgl@bgdev.pl>
Hi Bartosz,
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Provide a separate section in which pointers to early platform driver
> structs will be stored.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Thanks for your patch!
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -214,6 +214,16 @@
> #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
> #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
>
> +#ifdef CONFIG_EARLY_PLATFORM
> +#define EARLY_PLATFORM_DRIVERS_TABLE() \
> + . = ALIGN(8); \
Should this use STRUCT_ALIGN() instead?
> + VMLINUX_SYMBOL(__early_platform_drivers_table) = .; \
> + KEEP(*(__early_platform_drivers_table)) \
> + VMLINUX_SYMBOL(__early_platform_drivers_table_end) = .;
> +#else
> +#define EARLY_PLATFORM_DRIVERS_TABLE()
> +#endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox