Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver
From: Sean Paul @ 2018-06-05 22:59 UTC (permalink / raw)
  To: Sandeep Panda
  Cc: devicetree, ryadav, linux-arm-msm, dri-devel, abhinavk, hoegsberg,
	freedreno, chandanu
In-Reply-To: <1528177218-1051-3-git-send-email-spanda@codeaurora.org>

On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
> 
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
> 
> Changes in v1:
>  - Split the dt-bindings and the driver support into separate patches
>    (Andrzej Hajda).
>  - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
>    (Andrzej Hajda).
>  - Use macros to define the register offsets (Andrzej Hajda).
> 
> Changes in v2:
>  - Separate out edp panel specific HW resource handling from bridge
>    driver and create a separate edp panel drivers to handle panel
>    specific mode information and HW resources (Sean Paul).
>  - Replace pr_* APIs to DRM_* APIs to log error or debug information
>    (Sean Paul).
>  - Remove some of the unnecessary structure/variable from driver (Sean
>    Paul).
>  - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge"
>    (Sean Paul / Rob Herring).
>  - Remove most of the hard-coding and modified the bridge init sequence
>    based on current mode (Sean Paul).
>  - Remove the existing function to retrieve the EDID data and
>    implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul).
>  - Remove the dummy irq handler implementation, will add back the
>    proper irq handling later (Sean Paul).
>  - Capture the required enable gpios in a single array based on dt entry
>    instead of having individual descriptor for each gpio (Sean Paul).
> 
> Changes in v3:
>  - Remove usage of irq_gpio and replace it as "interrupts" property (Rob
>    Herring).
>  - Remove the unnecessary header file inclusions (Sean Paul).
>  - Rearrange the header files in alphabetical order (Sean Paul).
>  - Use regmap interface to perform i2c transactions.
>  - Update Copyright/License field and address other review comments
>    (Jordan Crouse).
> 
> Changes in v4:
>  - Update License/Copyright (Sean Paul).
>  - Add Kconfig and Makefile changes (Sean Paul).
>  - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios
>    will be handled by i2c master.
>  - Update required supplies names.
>  - Remove unnecessary goto statements (Sean Paul).
>  - Add mutex lock to power_ctrl API to avoid race conditions (Sean
>    Paul).
>  - Add support to parse reference clk frequency from dt(optional).
>  - Update the bridge chip enable/disable sequence.
> 
> Changes in v5:
>  - Fixed Kbuild test service reported warnings.
> 
> Changes in v6:
>  - Use PM runtime based ref-counting instead of local ref_count mechanism
>    (Stephen Boyd).
>  - Clean up some debug logs and indentations (Sean Paul).
>  - Simplify dp rate calculation (Sean Paul).
>  - Add support to configure refclk based on input REFCLK pin or DACP/N
>    pin (Stephen Boyd).
> 
> Changes in v7:
>  - Use static supply entries instead of dynamic allocation (Andrzej
>    Hajda).
>  - Defer bridge driver probe if panel is not probed (Andrzej Hajda).
>  - Update of_graph APIs for correct node reference management. (Andrzej
>    Hajda).
>  - Remove local display_mode object (Andrzej Hajda).
>  - Remove version id check function from driver.
> 
> Changes in v8:
>  - Move dsi register/attach function to bridge driver probe (Andrzej
>    Hajda).
>  - Introduce a new helper function to write 16bit words into consecutive
>    registers (Andrzej Hajda).
>  - Remove unnecessary macros (Andrzej Hajda).
> 
> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
> ---
>  drivers/gpu/drm/bridge/Kconfig        |   9 +
>  drivers/gpu/drm/bridge/Makefile       |   1 +
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 666 ++++++++++++++++++++++++++++++++++
>  3 files changed, 676 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..8153150 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -108,6 +108,15 @@ config DRM_TI_TFP410
>  	---help---
>  	  Texas Instruments TFP410 DVI/HDMI Transmitter driver
>  
> +config DRM_TI_SN65DSI86
> +	tristate "TI SN65DSI86 DSI to eDP bridge"
> +	depends on OF
> +	select DRM_KMS_HELPER
> +	select REGMAP_I2C
> +	select DRM_PANEL
> +	---help---
> +	  Texas Instruments SN65DSI86 DSI to eDP Bridge driver
> +
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>  
>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..3711be8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o

SN65DSI86 should be in front of TFP410 here and above.

>  obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 0000000..add6e0f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c

/snip

> +
> +#define REFCLK_LUT_SIZE	5
> +
> +/* clk frequencies supported by bridge in Hz in case derived from REFCLK pin */
> +static const u32 ti_sn_bridge_refclk_lut[] = {
> +	12000000,
> +	19200000,
> +	26000000,
> +	27000000,
> +	38400000,
> +};
> +
> +/* clk frequencies supported by bridge in Hz in case derived from DACP/N pin */
> +static const u32 ti_sn_bridge_dsiclk_lut[] = {
> +	468000000,
> +	384000000,
> +	416000000,
> +	486000000,
> +	460800000,
> +};
> +
> +static void ti_sn_bridge_set_refclk(struct ti_sn_bridge *pdata)
> +{
> +	int i = 0;
> +	u8 refclk_src;
> +	u32 refclk_rate;
> +	const u32 *refclk_lut;
> +
> +	if (pdata->refclk) {
> +		refclk_src = DPPLL_CLK_SRC_REFCLK;
> +		refclk_rate = clk_get_rate(pdata->refclk);
> +		refclk_lut = ti_sn_bridge_refclk_lut;
> +		clk_prepare_enable(pdata->refclk);
> +	} else {
> +		refclk_src = DPPLL_CLK_SRC_DSICLK;
> +		refclk_rate = ti_sn_bridge_get_dsi_freq(pdata) * 1000;
> +		refclk_lut = ti_sn_bridge_dsiclk_lut;
> +	}
> +
> +	/* for i equals to REFCLK_LUT_SIZE means default frequency */
> +	for (i = 0; i < REFCLK_LUT_SIZE; i++)

Instead of REFCLK_LUT_SIZE, use a local variable, ie:

        size_t refclk_lut_size;

        ...

        if(pdata->refclk) {
                ...
                refclk_lut = ti_sn_bridge_refclk_lut;
                refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_refclk_lut);
                ...
        } else {
                ...
                refclk_lut = ti_sn_bridge_dsiclk_lut;
                refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_dsiclk_lut);
        }

And remove REFCLK_LUT_SIZE.

> +		if (refclk_lut[i] == refclk_rate)
> +			break;
> +
> +	regmap_write(pdata->regmap, SN_REFCLK_FREQ_REG,
> +		     (refclk_src | (i << SN_DSIA_REFCLK_OFFSET)));
> +}
> +
> +/**
> + * LUT index corresponds to register value and
> + * LUT values corresponds to dp data rate supported
> + * by the bridge in Mbps unit.
> + */
> +static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
> +	0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
> +};
> +
> +static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
> +{
> +	unsigned int bit_rate_mhz, clk_freq_mhz, dp_rate_mhz;
> +	unsigned int val = 0, i = 0;
> +	struct drm_display_mode *mode =
> +		&pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> +	/* set DSIA clk frequency */
> +	bit_rate_mhz = (mode->clock / 1000) *
> +			mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> +	clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
> +
> +	/* for each increment in val, frequency increases by 5MHz */
> +	val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
> +		(((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
> +	regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> +
> +	/* set DP data rate */
> +	dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
> +							DP_CLK_FUDGE_DEN;
> +	for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
> +		if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
> +			break;
> +
> +	regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> +			   SN_DP_DATA_RATE_BITS, i << SN_DP_DATA_RATE_OFFSET);
> +}
> +
> +static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge *pdata)
> +{
> +	struct drm_display_mode *mode =
> +		&pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> +	ti_sn_bridge_write_u16(pdata, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
> +			       mode->hdisplay);
> +	ti_sn_bridge_write_u16(pdata, SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG,
> +			       mode->vdisplay);
> +	ti_sn_bridge_write_u16(pdata, SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG,
> +			       mode->hsync_end - mode->hsync_start);
> +	ti_sn_bridge_write_u16(pdata, SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG,
> +			       mode->vsync_end - mode->vsync_start);
> +
> +	regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_BACK_PORCH_REG,
> +		     (mode->htotal - mode->hsync_end) & 0xFF);
> +	regmap_write(pdata->regmap, SN_CHA_VERTICAL_BACK_PORCH_REG,
> +		     (mode->vtotal - mode->vsync_end) & 0xFF);
> +
> +	regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_FRONT_PORCH_REG,
> +		     (mode->hsync_start - mode->hdisplay) & 0xFF);
> +	regmap_write(pdata->regmap, SN_CHA_VERTICAL_FRONT_PORCH_REG,
> +		     (mode->vsync_start - mode->vdisplay) & 0xFF);
> +
> +	usleep_range(10000, 10500); /* 10ms delay recommended by spec */
> +}
> +
> +static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> +{
> +	struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +	unsigned int val = 0;
> +
> +	if (pdata->panel) {
> +		drm_panel_prepare(pdata->panel);
> +		/* in case drm_panel is connected then HPD is not supported */
> +		regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG,
> +				   SN_HPD_DISABLE_BIT, !0);

What is !0?

Sean

/snip

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v2 3/6] dt: bindings: add bindings for msa memory region
From: Brian Norris @ 2018-06-05 23:18 UTC (permalink / raw)
  To: Govind Singh
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	andy.gross-QSEj5FYQhm4dnm+yROfE0A,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
	david.brown-QSEj5FYQhm4dnm+yROfE0A,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring
In-Reply-To: <20180605123616.528-1-govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

+ Rob

On Tue, Jun 05, 2018 at 06:06:16PM +0530, Govind Singh wrote:
> Add device tree binding documentation details of msa
> memory region for ath10k qmi client for SDM845/APQ8098
> SoC into "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh <govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt          | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 7fd4e8ce4149..0efc47f4ba34 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -56,6 +56,8 @@ Optional properties:
>  				     the length can vary between hw versions.
>  - <supply-name>-supply: handle to the regulator device tree node
>  			   optional "supply-name" is "vdd-0.8-cx-mx".
> +- msa-fixed-region: phandle, specifier to children of reserved MSA memory.

As in reserved-memory/reserved-memory.txt? Might refer to that doc here.
Or is this some other kind of reserved memory?

If the former, it's normally called just "memory-region", although
that does seem somewhat non-descriptive...

> +- msa-size: MSA memory size for fw internal use.

Do you really need both of these? It seems like your code uses one or
the other, not both. In which case, this is not a very good description,
because it sounds like they would go together.

Also, if you're not using standard/generic properties (e.g., the
aforementioned "memory-region" binding), you typically should use a
vendor prefix, like "qcom,msa-size".

Brian

>  
>  Example (to supply the calibration data alone):
>  
> @@ -133,6 +135,8 @@ wifi@18000000 {
>  		compatible = "qcom,wcn3990-wifi";
>  		reg = <0x18800000 0x800000>;
>  		reg-names = "membase";
> +		msa-fixed-region = <&wlan_msa_mem>;
> +		msa-size = <0x100000>;
>  		clocks = <&clock_gcc clk_aggre2_noc_clk>;
>  		clock-names = "smmu_aggre2_noc_clk"
>  		interrupts =
> -- 
> 2.17.0
> 

^ permalink raw reply

* Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor
From: Saravana Kannan @ 2018-06-05 23:26 UTC (permalink / raw)
  To: myungjoo.ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
	Mark Rutland
  Cc: Rajendra Nayak, Amit Kucheria, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20180528060014epcms1p87ec68a4d44f9447b06f979a87e545b7d@epcms1p8>



On 05/27/2018 11:00 PM, MyungJoo Ham wrote:
>> Many CPU architectures have caches that can scale independent of the CPUs.
>> Frequency scaling of the caches is necessary to make sure the cache is not
>> a performance bottleneck that leads to poor performance and power. The same
>> idea applies for RAM/DDR.
>>
>> To achieve this, this patch series adds a generic devfreq governor that can
>> listen to the frequency transitions of each CPU frequency domain and then
>> adjusts the frequency of the cache (or any devfreq device) based on the
>> frequency of the CPUs.
> I agree that we have some hardware pieces that want to configure
> frequencies based on the CPUfreq.
>
> Creating a devfreq governor that configures devfreq-freq
> based on incoming events (CPUFreq-transition-event in this case)
> is indeed a good idea.
>
> However, I would like to ask the followings:
> The overall code appears to be overly complex compared what you need.
> - Do you really need to revive "CPUFREQ POLICY" events for this?
> especially when you are going to look at "first CPU" only?
>
>
> Cheers,
> MyungJoo
>
Sorry, didn't notice this email earlier. My message filters seem to be 
messed up.

The POLICY notifiers are necessary for cases when all CPUs in a policy 
are hotplugged off -- we need to ignore their frequencies to avoid 
getting the devfreq device stuck at a high frequency. Looking at "first 
CPU" is just an optimization to ignore multiple transition notifiers for 
the each CPU in a policy -- we'd want to do that even if we don't have 
policy notifiers. Not having policy notifier won't really simplify the 
code by much. We'd be forced to check for policy->related_cpus for every 
transition notifier call if the CPU state hasn't been already initialized.

-Saravana

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

^ permalink raw reply

* 答复: [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
From: liwei (CM) @ 2018-06-06  0:48 UTC (permalink / raw)
  To: Valentin Schneider, robh+dt@kernel.org, mark.rutland@arm.com,
	catalin.marinas@arm.com, will.deacon@arm.com,
	vinholikatti@gmail.com, jejb@linux.vnet.ibm.com,
	martin.petersen@oracle.com, khilman@baylibre.com, arnd@arndb.de,
	gregory.clement@free-electrons.com,
	thomas.petazzoni@free-electrons.com,
	yamada.masahiro@socionext.com, riku.voipio@linaro.org,
	treding@nvidia.com, krzk@kernel.org, devicetree@vger.kernel.org
  Cc: guodong.xu@linaro.org, Chenfeng (puck), Gengjianfeng, zangleigang,
	Fengbaopeng (kevin, Kirin Solution Dept), john.stultz@linaro.org
In-Reply-To: <f9cde7df-2d4d-3d7e-5269-ef879211b2ee@arm.com>

Hi, Valentin

Thank you for your attention and work.

Thanks!

-----邮件原件-----
发件人: Valentin Schneider [mailto:valentin.schneider@arm.com] 
发送时间: 2018年6月5日 22:59
收件人: liwei (CM); robh+dt@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; khilman@baylibre.com; arnd@arndb.de; gregory.clement@free-electrons.com; thomas.petazzoni@free-electrons.com; yamada.masahiro@socionext.com; riku.voipio@linaro.org; treding@nvidia.com; krzk@kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-scsi@vger.kernel.org
抄送: zangleigang; Gengjianfeng; guodong.xu@linaro.org; Chenfeng (puck); john.stultz@linaro.org; Fengbaopeng (kevin, Kirin Solution Dept)
主题: Re: [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC

Hi,

On 25/05/18 10:17, Li Wei wrote:
> This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board.
> 
> Li Wei (5):
>   scsi: ufs: add Hisilicon ufs driver code
>   dt-bindings: scsi: ufs: add document for hisi-ufs
>   arm64: dts: add ufs dts node
>   arm64: defconfig: enable configs for Hisilicon ufs
>   arm64: defconfig: enable f2fs and squashfs
> 
>  Documentation/devicetree/bindings/ufs/ufs-hisi.txt |  41 ++
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |  10 +-
>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi          |  18 +
>  arch/arm64/configs/defconfig                       |  11 +
>  drivers/scsi/ufs/Kconfig                           |   9 +
>  drivers/scsi/ufs/Makefile                          |   1 +
>  drivers/scsi/ufs/ufs-hisi.c                        | 619 +++++++++++++++++++++
>  drivers/scsi/ufs/ufs-hisi.h                        | 115 ++++
>  8 files changed, 821 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>  create mode 100644 drivers/scsi/ufs/ufs-hisi.c
>  create mode 100644 drivers/scsi/ufs/ufs-hisi.h
> 
> Major changes in v10:
>  - solve review comments from Rob Herring.
>    *Modify the "reset-names" describe in ufs-hisi.txt binding file.
>    *List clocks in ufs-hisi.txt binding file.
>    *remove the "arst" and keep only "rst" in the binging files.
>    *remove the "arst" member from both dts and c code. 
> Major changes in v9:
>  - solve review comments from Rob Herring.
>    *remove freq-table-hz in ufs-hisi.txt binding file.
>    *Move the rst to the ufshcd_pltfm.txt common binding file.
>    *Modify the member "assert" of UFS host structure to "arst".
> Major changes in v8:
>  - solve review comments from zhangfei.
>    *Add Version history.
>  - solve review comments from Rob Herring.
>    *remove freq-table-hz.
>  -  solve review comments from Riku Voipio.
>    *Add MODULE_DEVICE_TABLE for ufs driver.
> 

Tested on top of linux-next (4.17.0-next-20180605), I can reliably load
my debian userspace flashed on the 'system' fastboot partition.

Tested-by: Valentin Schneider <valentin.schneider@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* 答复: [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
From: liwei (CM) @ 2018-06-06  0:48 UTC (permalink / raw)
  To: Valentin Schneider, robh+dt@kernel.org, mark.rutland@arm.com,
	catalin.marinas@arm.com, will.deacon@arm.com,
	vinholikatti@gmail.com, jejb@linux.vnet.ibm.com,
	martin.petersen@oracle.com, khilman@baylibre.com, arnd@arndb.de,
	gregory.clement@free-electrons.com,
	thomas.petazzoni@free-electrons.com,
	yamada.masahiro@socionext.com, riku.voipio@linaro.org,
	treding@nvidia.com, krzk@kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-scsi@vger.kernel.org
  Cc: zangleigang, Gengjianfeng, guodong.xu@linaro.org, Chenfeng (puck),
	john.stultz@linaro.org,
	"kevin,,  <fengbaopeng@hisilicon.com>" <Fengbaopeng>
In-Reply-To: <f9cde7df-2d4d-3d7e-5269-ef879211b2ee@arm.com>

Hi, Valentin

Thank you for your attention and work.

Thanks!

-----邮件原件-----
发件人: Valentin Schneider [mailto:valentin.schneider@arm.com] 
发送时间: 2018年6月5日 22:59
收件人: liwei (CM); robh+dt@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; khilman@baylibre.com; arnd@arndb.de; gregory.clement@free-electrons.com; thomas.petazzoni@free-electrons.com; yamada.masahiro@socionext.com; riku.voipio@linaro.org; treding@nvidia.com; krzk@kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-scsi@vger.kernel.org
抄送: zangleigang; Gengjianfeng; guodong.xu@linaro.org; Chenfeng (puck); john.stultz@linaro.org; Fengbaopeng (kevin, Kirin Solution Dept)
主题: Re: [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC

Hi,

On 25/05/18 10:17, Li Wei wrote:
> This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board.
> 
> Li Wei (5):
>   scsi: ufs: add Hisilicon ufs driver code
>   dt-bindings: scsi: ufs: add document for hisi-ufs
>   arm64: dts: add ufs dts node
>   arm64: defconfig: enable configs for Hisilicon ufs
>   arm64: defconfig: enable f2fs and squashfs
> 
>  Documentation/devicetree/bindings/ufs/ufs-hisi.txt |  41 ++
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |  10 +-
>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi          |  18 +
>  arch/arm64/configs/defconfig                       |  11 +
>  drivers/scsi/ufs/Kconfig                           |   9 +
>  drivers/scsi/ufs/Makefile                          |   1 +
>  drivers/scsi/ufs/ufs-hisi.c                        | 619 +++++++++++++++++++++
>  drivers/scsi/ufs/ufs-hisi.h                        | 115 ++++
>  8 files changed, 821 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>  create mode 100644 drivers/scsi/ufs/ufs-hisi.c
>  create mode 100644 drivers/scsi/ufs/ufs-hisi.h
> 
> Major changes in v10:
>  - solve review comments from Rob Herring.
>    *Modify the "reset-names" describe in ufs-hisi.txt binding file.
>    *List clocks in ufs-hisi.txt binding file.
>    *remove the "arst" and keep only "rst" in the binging files.
>    *remove the "arst" member from both dts and c code. 
> Major changes in v9:
>  - solve review comments from Rob Herring.
>    *remove freq-table-hz in ufs-hisi.txt binding file.
>    *Move the rst to the ufshcd_pltfm.txt common binding file.
>    *Modify the member "assert" of UFS host structure to "arst".
> Major changes in v8:
>  - solve review comments from zhangfei.
>    *Add Version history.
>  - solve review comments from Rob Herring.
>    *remove freq-table-hz.
>  -  solve review comments from Riku Voipio.
>    *Add MODULE_DEVICE_TABLE for ufs driver.
> 

Tested on top of linux-next (4.17.0-next-20180605), I can reliably load
my debian userspace flashed on the 'system' fastboot partition.

Tested-by: Valentin Schneider <valentin.schneider@arm.com>

^ permalink raw reply

* Re: [PATCH v2 1/5] media: venus: add a routine to reset ARM9
From: Alexandre Courbot @ 2018-06-06  1:34 UTC (permalink / raw)
  To: vkoul
  Cc: Stanimir Varbanov, vgarodia, Hans Verkuil, Mauro Carvalho Chehab,
	robh, mark.rutland, andy.gross, bjorn.andersson,
	Linux Media Mailing List, LKML, linux-arm-msm, linux-soc,
	devicetree
In-Reply-To: <20180605105716.GT16230@vkoul-mobl>

On Tue, Jun 5, 2018 at 7:57 PM Vinod <vkoul@kernel.org> wrote:
>
> On 02-06-18, 01:15, Stanimir Varbanov wrote:
> > Hi Vikash,
> >
> > On  1.06.2018 23:26, Vikash Garodia wrote:
> > > Add a new routine to reset the ARM9 and brings it
> > > out of reset. This is in preparation to add PIL
> > > functionality in venus driver.
> >
> > please squash this patch with 4/5. I don't see a reason to add a function
> > which is not used. Shouldn't this produce gcc warnings?
>
> Yes this would but in a multi patch series that is okay as subsequent
> patches would use that and end result in no warning.

Except during bisect.

>
> Splitting logically is good and typical practice in kernel to add the
> routine followed by usages..

Is it in this case though? If this code was shared across multiple
users I could understand but this function is only used locally (and
only in one place IIUC). Also the patch is not so big that the code
would become confusing if this was squashed into 4/5. I don't see any
reason to keep this separate.

^ permalink raw reply

* Re: [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
From: Phil Reid @ 2018-06-06  2:03 UTC (permalink / raw)
  To: Brian Norris, Sebastian Reichel
  Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Rhyland Klein,
	Alexandru Stan, Guenter Roeck, Doug Anderson
In-Reply-To: <20180602012900.181352-1-briannorris@chromium.org>

G'day Brian,

One comment below.

On 2/06/2018 09:28, Brian Norris wrote:
> This driver was originally submitted for the TI BQ20Z75 battery IC
> (commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
> IC")) and later renamed to express generic SBS support. While it's
> mostly true that this driver implemented a standard SBS command set, it
> takes liberties with the REG_MANUFACTURER_DATA register. This register
> is specified in the SBS spec, but it doesn't make any mention of what
> its actual contents are.
> 
> We've sort of noticed this optionality previously, with commit
> 17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
> optional"), where we found that some batteries NAK writes to this
> register.
> 
> What this really means is that so far, we've just been lucky that most
> batteries have either been compatible with the TI chip, or else at least
> haven't reported highly-unexpected values.
> 
> For instance, one battery I have here seems to report either 0x0000 or
> 0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
> match either Wake Up (bits[11:8] = 0000b) or Normal Discharge
> (bits[11:8] = 0001b) status for the TI part [1], they don't seem to
> actually correspond to real states (for instance, I never see 0101b =
> Charge, even when charging).
> 
> On other batteries, I'm getting apparently random data in return, which
> means that occasionally, we interpret this as "battery not present" or
> "battery is not healthy".
> 
> All in all, it seems to be a really bad idea to make assumptions about
> REG_MANUFACTURER_DATA, unless we already know what battery we're using.
> Therefore, this patch reimplements the "present" and "health" checks to
> the following on most SBS batteries:
> 
> 1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
>     that gives us much useful here
> 2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
>     battery is present
> 
> Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
> no proof that this is useful and supported.
> 
> If someone explicitly provided a 'ti,bq20z75' compatible property, then
> we retain the existing TI command behaviors.
> 
> [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> Acked-by: Rhyland Klein <rklein@nvidia.com>
> ---
> v2:
>   * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
>   * use if/else instead of switch/case
> 
> v3:
>   * pull 'return 0' out of if/else, to satisfy braindead tooling
> ---
>   drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++-----
>   1 file changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
> index 83d7b4115857..a9691ea42f44 100644
> --- a/drivers/power/supply/sbs-battery.c
> +++ b/drivers/power/supply/sbs-battery.c
> @@ -23,6 +23,7 @@
>   #include <linux/kernel.h>
>   #include <linux/module.h>
>   #include <linux/of.h>
> +#include <linux/of_device.h>
>   #include <linux/power/sbs-battery.h>
>   #include <linux/power_supply.h>
>   #include <linux/slab.h>
> @@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
>   	POWER_SUPPLY_PROP_MODEL_NAME
>   };
>   
> +/* Supports special manufacturer commands from TI BQ20Z75 IC. */
> +#define SBS_FLAGS_TI_BQ20Z75		BIT(0)
> +
>   struct sbs_info {
>   	struct i2c_client		*client;
>   	struct power_supply		*power_supply;
> @@ -168,6 +172,7 @@ struct sbs_info {
>   	u32				poll_retry_count;
>   	struct delayed_work		work;
>   	struct mutex			mode_lock;
> +	u32				flags;
>   };
>   
>   static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
> @@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval)
>   static int sbs_get_battery_presence_and_health(
>   	struct i2c_client *client, enum power_supply_property psp,
>   	union power_supply_propval *val)
> +{
> +	int ret;
> +
> +	if (psp == POWER_SUPPLY_PROP_PRESENT) {
> +		/* Dummy command; if it succeeds, battery is present. */
> +		ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
> +		if (ret < 0)
> +			val->intval = 0; /* battery disconnected */
> +		else
> +			val->intval = 1; /* battery present */
> +	} else { /* POWER_SUPPLY_PROP_HEALTH */
> +		/* SBS spec doesn't have a general health command. */
> +		val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
> +	}
> +
> +	return 0;
> +}
> +
> +static int sbs_get_ti_battery_presence_and_health(
> +	struct i2c_client *client, enum power_supply_property psp,
> +	union power_supply_propval *val)
>   {
>   	s32 ret;
>   
> @@ -600,7 +626,12 @@ static int sbs_get_property(struct power_supply *psy,
>   	switch (psp) {
>   	case POWER_SUPPLY_PROP_PRESENT:
>   	case POWER_SUPPLY_PROP_HEALTH:
> -		ret = sbs_get_battery_presence_and_health(client, psp, val);
> +		if (client->flags & SBS_FLAGS_TI_BQ20Z75)
> +			ret = sbs_get_ti_battery_presence_and_health(client,
> +								     psp, val);
> +		else
> +			ret = sbs_get_battery_presence_and_health(client, psp,
> +								  val);
>   		if (psp == POWER_SUPPLY_PROP_PRESENT)
>   			return 0;
>   		break;
> @@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client,
>   	if (!chip)
>   		return -ENOMEM;
>   
> +	chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev);
>   	chip->client = client;
>   	chip->enable_detection = false;
>   	psy_cfg.of_node = client->dev.of_node;
> @@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev)
>   	if (chip->poll_time > 0)
>   		cancel_delayed_work_sync(&chip->work);
>   
> -	/*
> -	 * Write to manufacturer access with sleep command.
> -	 * Support is manufacturer dependend, so ignore errors.
> -	 */
> -	sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
> -		MANUFACTURER_ACCESS_SLEEP);
> +	if (chip->flags & SBS_FLAGS_TI_BQ20Z75) {
> +		/*
> +		 * Write to manufacturer access with sleep command.
> +		 * Support is manufacturer dependent, so ignore errors.
> +		 */
> +		sbs_write_word_data(client,
> +				    sbs_data[REG_MANUFACTURER_DATA].addr,
> +				    MANUFACTURER_ACCESS_SLEEP);
> +	}

Now that this is only being done for only TI devices that support this I would think the comment
about ignoring errors needs to go, and errors checks added.
Ditto in the new sbs_get_ti_battery_presence_and_health()



>   
>   	return 0;
>   }
> @@ -941,7 +976,10 @@ MODULE_DEVICE_TABLE(i2c, sbs_id);
>   
>   static const struct of_device_id sbs_dt_ids[] = {
>   	{ .compatible = "sbs,sbs-battery" },
> -	{ .compatible = "ti,bq20z75" },
> +	{
> +		.compatible = "ti,bq20z75",
> +		.data = (void *)SBS_FLAGS_TI_BQ20Z75,
> +	},
>   	{ }
>   };
>   MODULE_DEVICE_TABLE(of, sbs_dt_ids);
> 


-- 
Regards
Phil Reid

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Viresh Kumar @ 2018-06-06  4:42 UTC (permalink / raw)
  To: Taniya Das
  Cc: Rafael J. Wysocki, linux-kernel, linux-pm, Stephen Boyd, robh,
	Rajendra Nayak, devicetree, skannan
In-Reply-To: <1528109194-16864-2-git-send-email-tdas@codeaurora.org>

On 04-06-18, 16:16, Taniya Das wrote:
> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> SoCs. This is required for managing the cpu frequency transitions which are
> controlled by firmware.
> 
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
>  .../bindings/cpufreq/cpufreq-qcom-fw.txt           | 173 +++++++++++++++++++++
>  1 file changed, 173 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
> new file mode 100644
> index 0000000..e3087ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
> @@ -0,0 +1,173 @@
> +Qualcomm Technologies, Inc. CPUFREQ Bindings
> +
> +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
> +SoCs to manage frequency in hardware. It is capable of controlling frequency
> +for multiple clusters.
> +
> +Properties:
> +- compatible
> +	Usage:		required
> +	Value type:	<string>
> +	Definition:	must be "qcom,cpufreq-fw".
> +
> +* Property qcom,freq-domain
> +Devices supporting freq-domain must set their "qcom,freq-domain" property with
> +phandle to a freq_domain_table in their DT node.
> +
> +* Frequency Domain Table Node
> +
> +This describes the frequency domain belonging to a device.
> +This node can have following properties:
> +
> +- reg
> +	Usage:		required
> +	Value type:	<prop-encoded-array>
> +	Definition:	Addresses and sizes for the memory of the perf
> +			, lut and enable bases.
> +			perf - indicates the base address for the desired
> +			performance state to be set.
> +			lut - indicates the look up table base address for the
> +			cpufreq	driver to read frequencies.
> +			enable - indicates the enable register for firmware.
> +- reg-names
> +	Usage:		required
> +	Value type:	<stringlist>
> +	Definition:	Address names. Must be "perf", "lut", "enable".
> +			Must be specified in the same order as the reg property.
> +
> +Example:
> +
> +Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
> +DCVS state together.
> +
> +/ {
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		CPU0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x0>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_0>;
> +			qcom,freq-domain = <&freq_domain_table0>;
> +			L2_0: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +				L3_0: l3-cache {
> +				      compatible = "cache";
> +				};
> +			};
> +		};
> +
> +		CPU1: cpu@100 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x100>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_100>;
> +			qcom,freq-domain = <&freq_domain_table0>;
> +			L2_100: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU2: cpu@200 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x200>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_200>;
> +			qcom,freq-domain = <&freq_domain_table0>;
> +			L2_200: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU3: cpu@300 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x300>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_300>;
> +			qcom,freq-domain = <&freq_domain_table0>;
> +			L2_300: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU4: cpu@400 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x400>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_400>;
> +			qcom,freq-domain = <&freq_domain_table1>;
> +			L2_400: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU5: cpu@500 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x500>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_500>;
> +			qcom,freq-domain = <&freq_domain_table1>;
> +			L2_500: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU6: cpu@600 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x600>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_600>;
> +			qcom,freq-domain = <&freq_domain_table1>;
> +			L2_600: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +
> +		CPU7: cpu@700 {
> +			device_type = "cpu";
> +			compatible = "qcom,kryo385";
> +			reg = <0x0 0x700>;
> +			enable-method = "psci";
> +			next-level-cache = <&L2_700>;
> +			qcom,freq-domain = <&freq_domain_table1>;
> +			L2_700: l2-cache {
> +				compatible = "cache";
> +				next-level-cache = <&L3_0>;
> +			};
> +		};
> +	};
> +
> +	qcom,cpufreq-fw {
> +		compatible = "qcom,cpufreq-fw";
> +
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		freq_domain_table0 : freq_table0 {
> +			reg = <0x17d43920 0x4>, <0x17d43110 0x500>,
> +				 <0x17d41000 0x4>;
> +			reg-names = "perf", "lut", "enable";
> +		};
> +
> +		freq_domain_table1 : freq_table1 {
> +			reg = <0x17d46120 0x4>, <0x17d45910 0x500>,
> +				<0x17d45800 0x4> ;
> +			reg-names = "perf", "lut", "enable";
> +		};
> +	};

Looks better now from design point of view now, no ugly CPU lists :)

Unless Rob finds something wrong with the bindings:

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply

* Re: [PATCH v2 5/5] venus: register separate driver for firmware device
From: Tomasz Figa @ 2018-06-06  4:46 UTC (permalink / raw)
  To: Rob Herring
  Cc: vgarodia, Hans Verkuil, Mauro Carvalho Chehab, Mark Rutland,
	Andy Gross, bjorn.andersson, Stanimir Varbanov,
	Linux Media Mailing List, Linux Kernel Mailing List,
	linux-arm-msm, linux-soc, devicetree, Alexandre Courbot
In-Reply-To: <20180605210758.GA19888@rob-hp-laptop>

Hi Rob,

On Wed, Jun 6, 2018 at 6:08 AM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Jun 02, 2018 at 01:56:08AM +0530, Vikash Garodia wrote:
> > A separate child device is added for video firmware.
> > This is needed to
> > [1] configure the firmware context bank with the desired SID.
> > [2] ensure that the iova for firmware region is from 0x0.
> >
> > Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
> > ---
> >  .../devicetree/bindings/media/qcom,venus.txt       |  8 +++-
> >  drivers/media/platform/qcom/venus/core.c           | 48 +++++++++++++++++++---
> >  drivers/media/platform/qcom/venus/firmware.c       | 20 ++++++++-
> >  drivers/media/platform/qcom/venus/firmware.h       |  2 +
> >  4 files changed, 71 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
> > index 00d0d1b..701cbe8 100644
> > --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
> > +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> > @@ -53,7 +53,7 @@
> >
> >  * Subnodes
> >  The Venus video-codec node must contain two subnodes representing
> > -video-decoder and video-encoder.
> > +video-decoder and video-encoder, one optional firmware subnode.
> >
> >  Every of video-encoder or video-decoder subnode should have:
> >
> > @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
> >                   power domain which is responsible for collapsing
> >                   and restoring power to the subcore.
> >
> > +The firmware sub node must contain the iommus specifiers for ARM9.
> > +
> >  * An Example
> >       video-codec@1d00000 {
> >               compatible = "qcom,msm8916-venus";
> > @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
> >                       clock-names = "core";
> >                       power-domains = <&mmcc VENUS_CORE1_GDSC>;
> >               };
> > +             venus-firmware {
> > +                     compatible = "qcom,venus-firmware-no-tz";
> > +                     iommus = <&apps_smmu 0x10b2 0x0>;
>
> This mostly looks like you are adding a node in order to create a
> platform device. DT is not the only way to create platform devices and
> shouldn't be used when the device is not really a separate h/w device.
> Plus it seems like it is debatable that you even need a driver.
>
> For iommus, just move it up to the parent (or add to existing prop).

As far as I understood the issue from reading this series and also
talking a bit with Stanimir, there are multiple (physical?) ports from
the Venus hardware block and that includes one dedicated for firmware
loading, which has IOVA range restrictions up to 6 MiBs or something
like that.

If we add the firmware port to the iommus property of the main node,
we would bind it to the same IOVA address space as the other ports and
so it would be part of the main full 32-bit IOMMU domain.

Best regards,
Tomasz

^ permalink raw reply

* Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
From: spanda-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-06-06  4:50 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, ryadav-sgV2jX0FEOL9JmXXK+q4OQ,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	robdclark-Re5JQEeQqe8AvxtiuMwx3w, nganji-sgV2jX0FEOL9JmXXK+q4OQ,
	seanpaul-F7+t8E8rja9g9hUCZPvPmw, abhinavk-sgV2jX0FEOL9JmXXK+q4OQ,
	hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
	freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	jsanka-sgV2jX0FEOL9JmXXK+q4OQ, chandanu-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <20180605152050.GA9677@rob-hp-laptop>

On 2018-06-05 20:50, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
>> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>> 
>> Changes in v1:
>>  - Rephrase the dt-binding descriptions to be more inline with 
>> existing
>>    bindings (Andrzej Hajda).
>>  - Add missing dt-binding that are parsed by corresponding driver
>>    (Andrzej Hajda).
>> 
>> Changes in v2:
>>  - Remove edp panel specific dt-binding entries. Only keep bridge
>>    specific entries (Sean Paul).
>>  - Remove custom-modes dt entry since its usage is removed from driver 
>> also (Sean Paul).
>>  - Remove is-pluggable dt entry since this will not be needed anymore 
>> (Sean Paul).
>> 
>> Changes in v3:
>>  - Remove irq-gpio dt entry and instead populate is an interrupt
>>    property (Rob Herring).
>> 
>> Changes in v4:
>>  - Add link to bridge chip datasheet (Stephen Boyd)
>>  - Add vpll and vcc regulator supply bindings (Stephen Boyd)
>>  - Add ref clk optional dt binding (Stephen Boyd)
>>  - Add gpio-controller optional dt binding (Stephen Boyd)
>> 
>> Changes in v5:
>>  - Use clock property to specify the input refclk (Stephen Boyd).
>>  - Update gpio cell and pwm cell numbers (Stephen Boyd).
>> 
>> Changes in v6:
>>  - Add property to mention the lane mapping scheme and polarity 
>> inversion
>>    (Stephen Boyd).
>> 
>> Changes in v7:
>>  - Detail description of lane mapping scheme dt property (Andrzej
>>    Hajda/ Rob Herring).
>>  - Removed HDP gpio binding, since the bridge uses IRQ signal to
>>    determine HPD, and IRQ property is already documented in binding.
>> 
>> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
>> ---
>>  .../bindings/display/bridge/ti,sn65dsi86.txt       | 109 
>> +++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> new file mode 100644
>> index 0000000..33329f9
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> @@ -0,0 +1,109 @@
>> +SN65DSI86 DSI to eDP bridge chip
>> +--------------------------------
>> +
>> +This is the binding for Texas Instruments SN65DSI86 bridge.
>> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
>> +
>> +Required properties:
>> +- compatible: Must be "ti,sn65dsi86"
>> +- reg: i2c address of the chip, 0x2d as per datasheet
>> +- enable-gpios: OF device-tree gpio specification for bridge_en pin 
>> (active high)
>> +
>> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
>> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
>> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
>> +- vcc-supply: A 1.2V supply that powers up the digital core.
>> +
>> +Optional properties:
>> +- interrupts: Specifier for the SN65DSI86 interrupt line.
>> +
>> +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID 
>> probing
>> +
>> +- gpio-controller: Marks the device has a GPIO controller.
>> +- #gpio-cells    : Should be two. The first cell is the pin number 
>> and
>> +                   the second cell is used to specify flags.
>> +                   See ../../gpio/gpio.txt for more information.
>> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description 
>> of
>> +               the cell formats.
>> +
>> +- clock-names: should be "refclk"
>> +- clocks: Specification for input reference clock. The reference
>> +	  clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
>> +
>> +- lane-mapping: Specification to describe the logical to physical 
>> lane
> 
> As I mentioned in v7, we already have a property for this. It's called
> 'data-lanes' and defined in media/video-interfaces.txt. Use that. If 
> you
> need polarity too, then add a property for that. And add it to
> video-interfaces.txt.

The data-lanes property mentioned in media/video-interfaces.txt is 
referring
to DSI/CSI lanes where assumption is clock lane is fixed at index 0. But 
here
the we want to mention about eDP lanes which do not have dedicated clock 
lane.
So can we still use the existing data-lanes property here?

> 
>> +		mapping scheme and polarity inversion of eDP lanes on PCB.
>> +		Each pair present at index n (where n lies between 0 and 3)
>> +		describes the lane mapping of logical lane to physical lane n
>> +		and the polarity(it should be either 1 or 0) of the physical lane 
>> n.
>> +
>> +		For example:
>> +		lane-mapping = <2 1>,
>> +				<1 0>,
>> +				<3 1>,
>> +				<0 0>;
>> +
>> +		The above mapping describes that logical lane 2 is mapped to
>> +		physical lane 0 and polarity of physical lane 0 is inverted,
>> +		logical lane 1 is mapped to physical lane 1 and polarity of
>> +		physical lane 1 is normal, logical lane 3 is mapped to physical
>> +		lane 2 and polarity of physical lane 2 is inverted, logical lane 0
>> +		is mapped to physical lane 4 and polarity of physical lane 3 is 
>> normal.
>> +
>> +		If this property is not mentioned then it is assumed that physical
>> +		lanes 0 through 3 are mapped to logical lanes 0 through 3 and 
>> polarity
>> +		of all physical lanes is normal.
>> +
>> +Required nodes:
>> +This device has two video ports. Their connections are modelled using 
>> the
>> +OF graph bindings specified in 
>> Documentation/devicetree/bindings/graph.txt.
>> +
>> +- Video port 0 for DSI input
>> +- Video port 1 for eDP output
>> +
>> +Example
>> +-------
>> +
>> +edp-bridge@2d {
>> +	compatible = "ti,sn65dsi86";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	reg = <0x2d>;
>> +
>> +	enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
>> +	interrupt-parent = <&gpio3>;
>> +	interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
>> +
>> +	vccio-supply = <&pm8916_l17>;
>> +	vcca-supply = <&pm8916_l6>;
>> +	vpll-supply = <&pm8916_l17>;
>> +	vcc-supply = <&pm8916_l6>;
>> +
>> +	clock-names = "refclk";
>> +	clocks = <&input_refclk>;
>> +
>> +	lane-mapping = <0 0>, /* Logical lane 0 is routed to  physical lane 
>> 0 (!inv) */
>> +		      <1 1>, /* Logical lane 1 is routed to physical lane 1 (inv) 
>> */
>> +		      <2 0>, /* Logical lane 2 is routed to physical lane 2 (!inv) 
>> */
>> +		      <3 1>; /* Logical lane 3 is routed to physical lane 3 (inv) 
>> */
>> +
>> +	ports {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		port@0 {
>> +			reg = <0>;
>> +
>> +			edp_bridge_in: endpoint {
>> +				remote-endpoint = <&dsi_out>;
>> +			};
>> +		};
>> +
>> +		port@1 {
>> +			reg = <1>;
>> +
>> +			edp_bridge_out: endpoint {
>> +				remote-endpoint = <&edp_panel_in>;
>> +			};
>> +		};
>> +	};
>> +}
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

^ permalink raw reply

* Re: [PATCH v5 3/4] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-06-06  5:10 UTC (permalink / raw)
  To: Rob Herring
  Cc: Matti Vaittinen, mturquette, sboyd, mark.rutland, lee.jones,
	lgirdwood, broonie, mazziesaccount, linux-clk, devicetree,
	linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180605154932.GA20204@rob-hp-laptop>

On Tue, Jun 05, 2018 at 09:49:32AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:53PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC clock output.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> >  .../bindings/clock/rohm,bd71837-clock.txt          | 38 ++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
> > new file mode 100644
> > index 000000000000..771acfe34114
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
> > @@ -0,0 +1,38 @@
> > +ROHM BD71837 Power Management Integrated Circuit clock bindings
> 
> This needs to be added to the MFD doc. One node should be covered by at 
> most 1 document.

I was thinking of that too. But then I asked why? I also thought that if
one knows there is clock block in the chip - where does he look for
binding document? From clock folder. Then I saw how bindings for
MAX77686 chip were written and thought that this is beneficial for all.
MFD document directs to clock and regulator docs and on othe other hand,
clock document clearly states that properties it describes must be
present "in main device node of the MFD chip".

Don't you think on searching for clock bindings should find something
from clock folder? I can follow your instruction here but I think
the user might be happy if he found something under bindings/clock for
clock related properties.

Br,
	Matti Vaittinen

^ permalink raw reply

* Re: [PATCH v5 2/4] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-06-06  5:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Matti Vaittinen, mturquette, sboyd, mark.rutland, lee.jones,
	lgirdwood, broonie, mazziesaccount, linux-clk, devicetree,
	linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180605154757.GA26812@rob-hp-laptop>

On Tue, Jun 05, 2018 at 09:47:57AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:30PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC MFD.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> >  .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt  | 76 ++++++++++++++++++++++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
> 
> I've replied on the prior version discussion. Please don't send new 
> versions if the last one is still under discussion.

Allright. I thought this was a good way to suggest something which I
thought might address your concerns. But you are correct, it is better
to continue discussion in one emai thread. Sorry for adding this
version. I'll write further replies in v4 thread untill we get some
conclusion.

Br,
	Matti Vaittinen

^ permalink raw reply

* [PATCH v2 0/3] arm64: allwinner: a64: Add initial support for Pinebook
From: Vasily Khoruzhick @ 2018-06-06  5:16 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, linux-arm-kernel, devicetree
  Cc: Vasily Khoruzhick

This series adds dts for Pinebook with few prerequisites - PWM and R_I2C
devices nodes.

v2: - add my signoff
    - add default pinmux option for PWM
    - add alternate pinmux option for R_I2C controller
    - add A64 compatible for R_I2C controller

Andre Przywara (1):
  arm64: dts: allwinner: a64: Add PWM controllers

Icenowy Zheng (2):
  arm64: dts: allwinner: a64: add R_I2C controller
  arm64: dts: allwinner: add support for Pinebook

 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-a64-pinebook.dts     | 280 ++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  56 ++++
 3 files changed, 337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts

-- 
2.17.1

^ permalink raw reply

* [PATCH v2 1/3] arm64: dts: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-06  5:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, linux-arm-kernel, devicetree
  Cc: Vasily Khoruzhick, Icenowy Zheng
In-Reply-To: <20180606051702.6478-1-anarsoul@gmail.com>

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
two groups of pinmuxes on PL bank, so it's called R_I2C.

Add support for this I2C controller and the pinmux which doesn't conflict
with RSB.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..dcf957b2e7c8 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -46,6 +46,7 @@
 #include <dt-bindings/clock/sun8i-r-ccu.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/reset/sun50i-a64-ccu.h>
+#include <dt-bindings/reset/sun8i-r-ccu.h>
 
 / {
 	interrupt-parent = <&gic>;
@@ -655,6 +656,18 @@
 			#reset-cells = <1>;
 		};
 
+		r_i2c: i2c@1f02400 {
+			compatible = "allwinner,sun50i-a64-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x01f02400 0x400>;
+			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&r_ccu CLK_APB0_I2C>;
+			resets = <&r_ccu RST_APB0_I2C>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		r_pio: pinctrl@1f02c00 {
 			compatible = "allwinner,sun50i-a64-r-pinctrl";
 			reg = <0x01f02c00 0x400>;
@@ -666,6 +679,17 @@
 			interrupt-controller;
 			#interrupt-cells = <3>;
 
+
+			r_i2c_pins: i2c {
+				pins = "PL0", "PL1";
+				function = "s_i2c";
+			};
+
+			r_i2c_pins_a: i2c-a {
+				pins = "PL8", "PL9";
+				function = "s_i2c";
+			};
+
 			r_rsb_pins: rsb {
 				pins = "PL0", "PL1";
 				function = "s_rsb";
-- 
2.17.1

^ permalink raw reply related

* [PATCH v2 2/3] arm64: dts: allwinner: a64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-06  5:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, linux-arm-kernel, devicetree
  Cc: Vasily Khoruzhick, Andre Przywara
In-Reply-To: <20180606051702.6478-1-anarsoul@gmail.com>

From: Andre Przywara <andre.przywara@arm.com>

The Allwinner A64 SoC features two PWM controllers, which are fully
compatible to the one used in the A13 and H3 chips.

Add the nodes for the devices (one for the "normal" PWM, the other for
the one in the CPUS domain) and the pins their outputs are connected to.

On the A64 the "normal" PWM is muxed together with one of the MDIO pins
used to communicate with the Ethernet PHY, so it won't be usable on many
boards. But the Pinebook laptop uses this pin for controlling the LCD
backlight.

On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
at the same location as the PWM pin on the RaspberryPi.

Tested on Pinebook and Teres-I

[vasily: fixed comment message as requested by Stefan Bruens, added default
         muxing options to pwm and r_pwm nodes]

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Harald Geyer <harald@ccbib.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index dcf957b2e7c8..360bb1a4a504 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -365,6 +365,11 @@
 				bias-pull-up;
 			};
 
+			pwm_pin: pwm_pin {
+				pins = "PD22";
+				function = "pwm";
+			};
+
 			rmii_pins: rmii_pins {
 				pins = "PD10", "PD11", "PD13", "PD14", "PD17",
 				       "PD18", "PD19", "PD20", "PD22", "PD23";
@@ -630,6 +635,17 @@
 			#interrupt-cells = <3>;
 		};
 
+		pwm: pwm@1c21400 {
+			compatible = "allwinner,sun50i-a64-pwm",
+				     "allwinner,sun5i-a13-pwm";
+			reg = <0x01c21400 0x400>;
+			clocks = <&osc24M>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pwm_pin>;
+			#pwm-cells = <3>;
+			status = "disabled";
+		};
+
 		rtc: rtc@1f00000 {
 			compatible = "allwinner,sun6i-a31-rtc";
 			reg = <0x01f00000 0x54>;
@@ -668,6 +684,17 @@
 			#size-cells = <0>;
 		};
 
+		r_pwm: pwm@1f03800 {
+			compatible = "allwinner,sun50i-a64-pwm",
+				     "allwinner,sun5i-a13-pwm";
+			reg = <0x01f03800 0x400>;
+			clocks = <&osc24M>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&r_pwm_pin>;
+			#pwm-cells = <3>;
+			status = "disabled";
+		};
+
 		r_pio: pinctrl@1f02c00 {
 			compatible = "allwinner,sun50i-a64-r-pinctrl";
 			reg = <0x01f02c00 0x400>;
@@ -690,6 +717,11 @@
 				function = "s_i2c";
 			};
 
+			r_pwm_pin: pwm {
+				pins = "PL10";
+				function = "s_pwm";
+			};
+
 			r_rsb_pins: rsb {
 				pins = "PL0", "PL1";
 				function = "s_rsb";
-- 
2.17.1

^ permalink raw reply related

* [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-06  5:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, linux-arm-kernel, devicetree
  Cc: Vasily Khoruzhick, Icenowy Zheng
In-Reply-To: <20180606051702.6478-1-anarsoul@gmail.com>

From: Icenowy Zheng <icenowy@aosc.xyz>

Pinebook is a A64-based laptop produced by Pine64, with the following
peripherals:

USB:
- Two external USB ports (one is directly connected to A64's OTG
controller, the other is under a internal hub connected to the host-only
controller.)
- USB HID keyboard and touchpad connected to the internal hub.
- USB UVC camera connected to the internal hub.

Power-related:
- A DC IN jack connected to AXP803's DCIN pin.
- A Li-Polymer battery connected to AXP803's battery pins.

Storage:
- An eMMC by Foresee on the main board (in the product revision of the
main board it's designed to be switchable).
- An external MicroSD card slot.

Display:
- An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
- A mini HDMI port.

Misc:
- A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
- A headphone jack connected to the SoC's internal codec.
- A debug UART port muxed with headphone jack.

This commit adds basical support for it.

[vasily: squashed several commits into one, added simplefb node, added usbphy
	 to ehci0 and ohci0 nodes and other cosmetic changes to dts]

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-a64-pinebook.dts     | 280 ++++++++++++++++++
 2 files changed, 281 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 8bebe7da5ed9..a8c6d0c6f2c5 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
new file mode 100644
index 000000000000..58253d6f9be1
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
+ * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+	model = "Pinebook";
+	compatible = "pine64,pinebook", "allwinner,sun50i-a64";
+
+	aliases {
+		serial0 = &uart0;
+		ethernet0 = &rtl8723cs;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 0 50000 0>;
+		brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>;
+		default-brightness-level = <2>;
+		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+
+		framebuffer-lcd {
+			panel-supply = <&reg_dc1sw>;
+			dvdd25-supply = <&reg_dldo2>;
+			dvdd12-supply = <&reg_fldo1>;
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+
+		lid_switch {
+			label = "Lid Switch";
+			gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			linux,can-disable;
+		};
+	};
+
+	reg_vcc3v3: vcc3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+	};
+};
+
+&ehci0 {
+	phys = <&usbphy 0>;
+	phy-names = "usb";
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+	cd-inverted;
+	disable-wp;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dldo4>;
+	vqmmc-supply = <&reg_eldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	rtl8723cs: wifi@1 {
+		reg = <1>;
+	};
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_eldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&ohci0 {
+	phys = <&usbphy 0>;
+	phy-names = "usb";
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&pwm {
+	status = "okay";
+};
+
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic@3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+/* The ANX6345 eDP-bridge is on r_i2c */
+&r_i2c {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&r_i2c_pins_a>;
+	status = "okay";
+};
+
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-csi";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+	regulator-name = "vcc-lcd";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-edp";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_eldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_eldo3 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vdd-1v8-csi";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_ldo_io0 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-usb";
+	status = "okay";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&usb_otg {
+	dr_mode = "host";
+};
+
+&usbphy {
+	usb0_vbus-supply = <&reg_ldo_io0>;
+	usb1_vbus-supply = <&reg_ldo_io0>;
+	status = "okay";
+};
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Icenowy Zheng @ 2018-06-06  5:20 UTC (permalink / raw)
  To: linux-arm-kernel, Vasily Khoruzhick, Maxime Ripard, Chen-Yu Tsai,
	Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
	devicetree
  Cc: Icenowy Zheng
In-Reply-To: <20180606051702.6478-4-anarsoul@gmail.com>



于 2018年6月6日 GMT+08:00 下午1:17:02, Vasily Khoruzhick <anarsoul@gmail.com> 写到:
>From: Icenowy Zheng <icenowy@aosc.xyz>

Could you change all the mail address to @aosc.io ?

>
>Pinebook is a A64-based laptop produced by Pine64, with the following
>peripherals:
>
>USB:
>- Two external USB ports (one is directly connected to A64's OTG
>controller, the other is under a internal hub connected to the
>host-only
>controller.)
>- USB HID keyboard and touchpad connected to the internal hub.
>- USB UVC camera connected to the internal hub.
>
>Power-related:
>- A DC IN jack connected to AXP803's DCIN pin.
>- A Li-Polymer battery connected to AXP803's battery pins.
>
>Storage:
>- An eMMC by Foresee on the main board (in the product revision of the
>main board it's designed to be switchable).
>- An external MicroSD card slot.
>
>Display:
>- An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
>- A mini HDMI port.
>
>Misc:
>- A Hall sensor designed to detect the status of lid, connected to GPIO
>PL12.
>- A headphone jack connected to the SoC's internal codec.
>- A debug UART port muxed with headphone jack.
>
>This commit adds basical support for it.
>
>[vasily: squashed several commits into one, added simplefb node, added
>usbphy
>	 to ehci0 and ohci0 nodes and other cosmetic changes to dts]
>
>Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>---
> arch/arm64/boot/dts/allwinner/Makefile        |   1 +
> .../dts/allwinner/sun50i-a64-pinebook.dts     | 280 ++++++++++++++++++
> 2 files changed, 281 insertions(+)
>create mode 100644
>arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>
>diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>b/arch/arm64/boot/dts/allwinner/Makefile
>index 8bebe7da5ed9..a8c6d0c6f2c5 100644
>--- a/arch/arm64/boot/dts/allwinner/Makefile
>+++ b/arch/arm64/boot/dts/allwinner/Makefile
>@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb
>sun50i-a64-pine64.dtb
>+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>new file mode 100644
>index 000000000000..58253d6f9be1
>--- /dev/null
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>@@ -0,0 +1,280 @@
>+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>+/*
>+ * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
>+ * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
>+ *
>+ */
>+
>+/dts-v1/;
>+
>+#include "sun50i-a64.dtsi"
>+
>+#include <dt-bindings/gpio/gpio.h>
>+#include <dt-bindings/input/input.h>
>+#include <dt-bindings/pwm/pwm.h>
>+
>+/ {
>+	model = "Pinebook";
>+	compatible = "pine64,pinebook", "allwinner,sun50i-a64";
>+
>+	aliases {
>+		serial0 = &uart0;
>+		ethernet0 = &rtl8723cs;
>+	};
>+
>+	backlight: backlight {
>+		compatible = "pwm-backlight";
>+		pwms = <&pwm 0 50000 0>;
>+		brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>;
>+		default-brightness-level = <2>;
>+		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>+	};
>+
>+	chosen {
>+		stdout-path = "serial0:115200n8";
>+
>+		framebuffer-lcd {
>+			panel-supply = <&reg_dc1sw>;
>+			dvdd25-supply = <&reg_dldo2>;
>+			dvdd12-supply = <&reg_fldo1>;
>+		};
>+	};
>+
>+	gpio_keys {
>+		compatible = "gpio-keys";
>+
>+		lid_switch {
>+			label = "Lid Switch";
>+			gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
>+			linux,input-type = <EV_SW>;
>+			linux,code = <SW_LID>;
>+			linux,can-disable;
>+		};
>+	};
>+
>+	reg_vcc3v3: vcc3v3 {
>+		compatible = "regulator-fixed";
>+		regulator-name = "vcc3v3";
>+		regulator-min-microvolt = <3300000>;
>+		regulator-max-microvolt = <3300000>;
>+	};
>+
>+	wifi_pwrseq: wifi_pwrseq {
>+		compatible = "mmc-pwrseq-simple";
>+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>+	};
>+};
>+
>+&ehci0 {
>+	phys = <&usbphy 0>;
>+	phy-names = "usb";
>+	status = "okay";
>+};
>+
>+&ehci1 {
>+	status = "okay";
>+};
>+
>+&mmc0 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&mmc0_pins>;
>+	vmmc-supply = <&reg_dcdc1>;
>+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>+	cd-inverted;
>+	disable-wp;
>+	bus-width = <4>;
>+	status = "okay";
>+};
>+
>+&mmc1 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&mmc1_pins>;
>+	vmmc-supply = <&reg_dldo4>;
>+	vqmmc-supply = <&reg_eldo1>;
>+	mmc-pwrseq = <&wifi_pwrseq>;
>+	bus-width = <4>;
>+	non-removable;
>+	status = "okay";
>+
>+	rtl8723cs: wifi@1 {
>+		reg = <1>;
>+	};
>+};
>+
>+&mmc2 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&mmc2_pins>;
>+	vmmc-supply = <&reg_dcdc1>;
>+	vqmmc-supply = <&reg_eldo1>;
>+	bus-width = <8>;
>+	non-removable;
>+	cap-mmc-hw-reset;
>+	mmc-hs200-1_8v;
>+	status = "okay";
>+};
>+
>+&ohci0 {
>+	phys = <&usbphy 0>;
>+	phy-names = "usb";
>+	status = "okay";
>+};
>+
>+&ohci1 {
>+	status = "okay";
>+};
>+
>+&pwm {
>+	status = "okay";
>+};
>+
>+&r_rsb {
>+	status = "okay";
>+
>+	axp803: pmic@3a3 {
>+		compatible = "x-powers,axp803";
>+		reg = <0x3a3>;
>+		interrupt-parent = <&r_intc>;
>+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>+	};
>+};
>+
>+/* The ANX6345 eDP-bridge is on r_i2c */
>+&r_i2c {
>+	clock-frequency = <100000>;
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&r_i2c_pins_a>;
>+	status = "okay";
>+};
>+
>+#include "axp803.dtsi"
>+
>+&reg_aldo1 {
>+	regulator-min-microvolt = <2800000>;
>+	regulator-max-microvolt = <2800000>;
>+	regulator-name = "vcc-csi";
>+};
>+
>+&reg_aldo2 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1800000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-pl";
>+};
>+
>+&reg_aldo3 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <2700000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-pll-avcc";
>+};
>+
>+&reg_dc1sw {
>+	regulator-name = "vcc-lcd";
>+};
>+
>+&reg_dcdc1 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-3v3";
>+};
>+
>+&reg_dcdc2 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1000000>;
>+	regulator-max-microvolt = <1300000>;
>+	regulator-name = "vdd-cpux";
>+};
>+
>+/* DCDC3 is polyphased with DCDC2 */
>+
>+&reg_dcdc5 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1200000>;
>+	regulator-max-microvolt = <1200000>;
>+	regulator-name = "vcc-dram";
>+};
>+
>+&reg_dcdc6 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1100000>;
>+	regulator-max-microvolt = <1100000>;
>+	regulator-name = "vdd-sys";
>+};
>+
>+&reg_dldo1 {
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-hdmi";
>+};
>+
>+&reg_dldo2 {
>+	regulator-min-microvolt = <2500000>;
>+	regulator-max-microvolt = <2500000>;
>+	regulator-name = "vcc-edp";
>+};
>+
>+&reg_dldo3 {
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "avdd-csi";
>+};
>+
>+&reg_dldo4 {
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-wifi";
>+};
>+
>+&reg_eldo1 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1800000>;
>+	regulator-max-microvolt = <1800000>;
>+	regulator-name = "cpvdd";
>+};
>+
>+&reg_eldo3 {
>+	regulator-min-microvolt = <1800000>;
>+	regulator-max-microvolt = <1800000>;
>+	regulator-name = "vdd-1v8-csi";
>+};
>+
>+&reg_fldo1 {
>+	regulator-min-microvolt = <1200000>;
>+	regulator-max-microvolt = <1200000>;
>+	regulator-name = "vcc-1v2-hsic";
>+};
>+
>+&reg_fldo2 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <1100000>;
>+	regulator-max-microvolt = <1100000>;
>+	regulator-name = "vdd-cpus";
>+};
>+
>+&reg_ldo_io0 {
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-usb";
>+	status = "okay";
>+};
>+
>+&reg_rtc_ldo {
>+	regulator-name = "vcc-rtc";
>+};
>+
>+&uart0 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&uart0_pins_a>;
>+	status = "okay";
>+};
>+
>+&usb_otg {
>+	dr_mode = "host";
>+};
>+
>+&usbphy {
>+	usb0_vbus-supply = <&reg_ldo_io0>;
>+	usb1_vbus-supply = <&reg_ldo_io0>;
>+	status = "okay";
>+};

_______________________________________________
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 v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-06  5:23 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Mark Rutland, devicetree, Maxime Ripard, Catalin Marinas,
	Will Deacon, Chen-Yu Tsai, Rob Herring, Icenowy Zheng, arm-linux
In-Reply-To: <6FB4B99D-5A98-4E6F-B7F5-09063DAAF4A2@aosc.io>

OK, will do.

On Tue, Jun 5, 2018 at 10:20 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2018年6月6日 GMT+08:00 下午1:17:02, Vasily Khoruzhick <anarsoul@gmail.com> 写到:
>>From: Icenowy Zheng <icenowy@aosc.xyz>
>
> Could you change all the mail address to @aosc.io ?
>
>>
>>Pinebook is a A64-based laptop produced by Pine64, with the following
>>peripherals:
>>
>>USB:
>>- Two external USB ports (one is directly connected to A64's OTG
>>controller, the other is under a internal hub connected to the
>>host-only
>>controller.)
>>- USB HID keyboard and touchpad connected to the internal hub.
>>- USB UVC camera connected to the internal hub.
>>
>>Power-related:
>>- A DC IN jack connected to AXP803's DCIN pin.
>>- A Li-Polymer battery connected to AXP803's battery pins.
>>
>>Storage:
>>- An eMMC by Foresee on the main board (in the product revision of the
>>main board it's designed to be switchable).
>>- An external MicroSD card slot.
>>
>>Display:
>>- An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
>>- A mini HDMI port.
>>
>>Misc:
>>- A Hall sensor designed to detect the status of lid, connected to GPIO
>>PL12.
>>- A headphone jack connected to the SoC's internal codec.
>>- A debug UART port muxed with headphone jack.
>>
>>This commit adds basical support for it.
>>
>>[vasily: squashed several commits into one, added simplefb node, added
>>usbphy
>>        to ehci0 and ohci0 nodes and other cosmetic changes to dts]
>>
>>Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>---
>> arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>> .../dts/allwinner/sun50i-a64-pinebook.dts     | 280 ++++++++++++++++++
>> 2 files changed, 281 insertions(+)
>>create mode 100644
>>arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>
>>diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>>b/arch/arm64/boot/dts/allwinner/Makefile
>>index 8bebe7da5ed9..a8c6d0c6f2c5 100644
>>--- a/arch/arm64/boot/dts/allwinner/Makefile
>>+++ b/arch/arm64/boot/dts/allwinner/Makefile
>>@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb
>>sun50i-a64-pine64.dtb
>>+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>new file mode 100644
>>index 000000000000..58253d6f9be1
>>--- /dev/null
>>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>@@ -0,0 +1,280 @@
>>+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>+/*
>>+ * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
>>+ * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
>>+ *
>>+ */
>>+
>>+/dts-v1/;
>>+
>>+#include "sun50i-a64.dtsi"
>>+
>>+#include <dt-bindings/gpio/gpio.h>
>>+#include <dt-bindings/input/input.h>
>>+#include <dt-bindings/pwm/pwm.h>
>>+
>>+/ {
>>+      model = "Pinebook";
>>+      compatible = "pine64,pinebook", "allwinner,sun50i-a64";
>>+
>>+      aliases {
>>+              serial0 = &uart0;
>>+              ethernet0 = &rtl8723cs;
>>+      };
>>+
>>+      backlight: backlight {
>>+              compatible = "pwm-backlight";
>>+              pwms = <&pwm 0 50000 0>;
>>+              brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>;
>>+              default-brightness-level = <2>;
>>+              enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>>+      };
>>+
>>+      chosen {
>>+              stdout-path = "serial0:115200n8";
>>+
>>+              framebuffer-lcd {
>>+                      panel-supply = <&reg_dc1sw>;
>>+                      dvdd25-supply = <&reg_dldo2>;
>>+                      dvdd12-supply = <&reg_fldo1>;
>>+              };
>>+      };
>>+
>>+      gpio_keys {
>>+              compatible = "gpio-keys";
>>+
>>+              lid_switch {
>>+                      label = "Lid Switch";
>>+                      gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
>>+                      linux,input-type = <EV_SW>;
>>+                      linux,code = <SW_LID>;
>>+                      linux,can-disable;
>>+              };
>>+      };
>>+
>>+      reg_vcc3v3: vcc3v3 {
>>+              compatible = "regulator-fixed";
>>+              regulator-name = "vcc3v3";
>>+              regulator-min-microvolt = <3300000>;
>>+              regulator-max-microvolt = <3300000>;
>>+      };
>>+
>>+      wifi_pwrseq: wifi_pwrseq {
>>+              compatible = "mmc-pwrseq-simple";
>>+              reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>>+      };
>>+};
>>+
>>+&ehci0 {
>>+      phys = <&usbphy 0>;
>>+      phy-names = "usb";
>>+      status = "okay";
>>+};
>>+
>>+&ehci1 {
>>+      status = "okay";
>>+};
>>+
>>+&mmc0 {
>>+      pinctrl-names = "default";
>>+      pinctrl-0 = <&mmc0_pins>;
>>+      vmmc-supply = <&reg_dcdc1>;
>>+      cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>>+      cd-inverted;
>>+      disable-wp;
>>+      bus-width = <4>;
>>+      status = "okay";
>>+};
>>+
>>+&mmc1 {
>>+      pinctrl-names = "default";
>>+      pinctrl-0 = <&mmc1_pins>;
>>+      vmmc-supply = <&reg_dldo4>;
>>+      vqmmc-supply = <&reg_eldo1>;
>>+      mmc-pwrseq = <&wifi_pwrseq>;
>>+      bus-width = <4>;
>>+      non-removable;
>>+      status = "okay";
>>+
>>+      rtl8723cs: wifi@1 {
>>+              reg = <1>;
>>+      };
>>+};
>>+
>>+&mmc2 {
>>+      pinctrl-names = "default";
>>+      pinctrl-0 = <&mmc2_pins>;
>>+      vmmc-supply = <&reg_dcdc1>;
>>+      vqmmc-supply = <&reg_eldo1>;
>>+      bus-width = <8>;
>>+      non-removable;
>>+      cap-mmc-hw-reset;
>>+      mmc-hs200-1_8v;
>>+      status = "okay";
>>+};
>>+
>>+&ohci0 {
>>+      phys = <&usbphy 0>;
>>+      phy-names = "usb";
>>+      status = "okay";
>>+};
>>+
>>+&ohci1 {
>>+      status = "okay";
>>+};
>>+
>>+&pwm {
>>+      status = "okay";
>>+};
>>+
>>+&r_rsb {
>>+      status = "okay";
>>+
>>+      axp803: pmic@3a3 {
>>+              compatible = "x-powers,axp803";
>>+              reg = <0x3a3>;
>>+              interrupt-parent = <&r_intc>;
>>+              interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>+      };
>>+};
>>+
>>+/* The ANX6345 eDP-bridge is on r_i2c */
>>+&r_i2c {
>>+      clock-frequency = <100000>;
>>+      pinctrl-names = "default";
>>+      pinctrl-0 = <&r_i2c_pins_a>;
>>+      status = "okay";
>>+};
>>+
>>+#include "axp803.dtsi"
>>+
>>+&reg_aldo1 {
>>+      regulator-min-microvolt = <2800000>;
>>+      regulator-max-microvolt = <2800000>;
>>+      regulator-name = "vcc-csi";
>>+};
>>+
>>+&reg_aldo2 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1800000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-pl";
>>+};
>>+
>>+&reg_aldo3 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <2700000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-pll-avcc";
>>+};
>>+
>>+&reg_dc1sw {
>>+      regulator-name = "vcc-lcd";
>>+};
>>+
>>+&reg_dcdc1 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <3300000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-3v3";
>>+};
>>+
>>+&reg_dcdc2 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1000000>;
>>+      regulator-max-microvolt = <1300000>;
>>+      regulator-name = "vdd-cpux";
>>+};
>>+
>>+/* DCDC3 is polyphased with DCDC2 */
>>+
>>+&reg_dcdc5 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1200000>;
>>+      regulator-max-microvolt = <1200000>;
>>+      regulator-name = "vcc-dram";
>>+};
>>+
>>+&reg_dcdc6 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1100000>;
>>+      regulator-max-microvolt = <1100000>;
>>+      regulator-name = "vdd-sys";
>>+};
>>+
>>+&reg_dldo1 {
>>+      regulator-min-microvolt = <3300000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-hdmi";
>>+};
>>+
>>+&reg_dldo2 {
>>+      regulator-min-microvolt = <2500000>;
>>+      regulator-max-microvolt = <2500000>;
>>+      regulator-name = "vcc-edp";
>>+};
>>+
>>+&reg_dldo3 {
>>+      regulator-min-microvolt = <3300000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "avdd-csi";
>>+};
>>+
>>+&reg_dldo4 {
>>+      regulator-min-microvolt = <3300000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-wifi";
>>+};
>>+
>>+&reg_eldo1 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1800000>;
>>+      regulator-max-microvolt = <1800000>;
>>+      regulator-name = "cpvdd";
>>+};
>>+
>>+&reg_eldo3 {
>>+      regulator-min-microvolt = <1800000>;
>>+      regulator-max-microvolt = <1800000>;
>>+      regulator-name = "vdd-1v8-csi";
>>+};
>>+
>>+&reg_fldo1 {
>>+      regulator-min-microvolt = <1200000>;
>>+      regulator-max-microvolt = <1200000>;
>>+      regulator-name = "vcc-1v2-hsic";
>>+};
>>+
>>+&reg_fldo2 {
>>+      regulator-always-on;
>>+      regulator-min-microvolt = <1100000>;
>>+      regulator-max-microvolt = <1100000>;
>>+      regulator-name = "vdd-cpus";
>>+};
>>+
>>+&reg_ldo_io0 {
>>+      regulator-min-microvolt = <3300000>;
>>+      regulator-max-microvolt = <3300000>;
>>+      regulator-name = "vcc-usb";
>>+      status = "okay";
>>+};
>>+
>>+&reg_rtc_ldo {
>>+      regulator-name = "vcc-rtc";
>>+};
>>+
>>+&uart0 {
>>+      pinctrl-names = "default";
>>+      pinctrl-0 = <&uart0_pins_a>;
>>+      status = "okay";
>>+};
>>+
>>+&usb_otg {
>>+      dr_mode = "host";
>>+};
>>+
>>+&usbphy {
>>+      usb0_vbus-supply = <&reg_ldo_io0>;
>>+      usb1_vbus-supply = <&reg_ldo_io0>;
>>+      status = "okay";
>>+};

_______________________________________________
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 v7 3/3] gpio: pca953x: fix address calculation for pcal6524
From: H. Nikolaus Schaller @ 2018-06-06  5:33 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Andy Shevchenko, Kumar Gala, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Linus Walleij, Alexandre Courbot,
	devicetree, open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
	Discussions about the Letux Kernel, kernel
In-Reply-To: <20180605203941.GA28143@amd>

Hi,

> Am 05.06.2018 um 22:39 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
>> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
>>>> The register constants are so far defined in a way that they fit
>>>> for the pcal9555a when shifted by the number of banks, i.e. are
>>>> multiplied by 2 in the accessor function.
>>>> 
>>>> Now, the pcal6524 has 3 banks which means the relative offset
>>>> is multiplied by 4 for the standard registers.
>>>> 
>>>> Simply applying the bit shift to the extended registers gives
>>>> a wrong result, since the base offset is already included in
>>>> the offset.
>>>> 
>>>> Therefore, we have to add code to the 24 bit accessor functions
>>>> that adjusts the register number for these exended registers.
>>>> 
>>>> The formula finally used was developed and proposed by
>>>> Andy Shevchenko <andy.shevchenko@gmail.com>.
>> 
>>>>      int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
>>>> +     int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
>>>> +     int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>> 
>>> Is this reasonable to do on each register access? Compiler will not be
>>> able to optimize out fls and shifts, right?
>> 
>> On modern CPUs fls() is one assembly command. OTOH, any proposal to do
>> this better?
>> 
>> What I can see is that bank_shift is invariant to the function, and
>> maybe cached.
> 
> Yes, I thought that caching bank_shift might be good idea. I thought
> it was constant for given chip...

Yes, it is an f(chip), but the question that comes to my mind is if
optimization is worth any effort. This is an accessor method over i2c
which tends to be slow (100 / 400kHz SCL) compared to the CPU. So saving
1 or 2 CPU cycles here doesn't seem to be a significant improvement.
Maybe it is more valuable to improve the code path through the i2c core?

BR,
Nikolaus

^ permalink raw reply

* Re: [PATCH v2 5/5] venus: register separate driver for firmware device
From: Tomasz Figa @ 2018-06-06  5:41 UTC (permalink / raw)
  To: Stanimir Varbanov
  Cc: vgarodia, Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Mark Rutland, Andy Gross, bjorn.andersson,
	Linux Media Mailing List, Linux Kernel Mailing List,
	linux-arm-msm, linux-soc, devicetree, Alexandre Courbot,
	Arnd Bergmann
In-Reply-To: <fd74c277-e8d3-a026-fbd2-914a029e8efe@linaro.org>

On Tue, Jun 5, 2018 at 5:45 PM Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
>
> Cc: Arnd
>
> On 06/05/2018 07:08 AM, Tomasz Figa wrote:
> > On Mon, Jun 4, 2018 at 10:56 PM Stanimir Varbanov
> > <stanimir.varbanov@linaro.org> wrote:
> >>
> >> Hi Tomasz,
> >>
> >> On 06/04/2018 04:18 PM, Tomasz Figa wrote:
> >>> Hi Vikash,
> >>>
> >>> On Sat, Jun 2, 2018 at 5:27 AM Vikash Garodia <vgarodia@codeaurora.org> wrote:
> >>>> +static int __init venus_init(void)
> >>>> +{
> >>>> +       int ret;
> >>>> +
> >>>> +       ret = platform_driver_register(&qcom_video_firmware_driver);
> >>>> +       if (ret)
> >>>> +               return ret;
> >>>
> >>> Do we really need this firmware driver? As far as I can see, the
> >>> approach used here should work even without any driver bound to the
> >>> firmware device.
> >>
> >> We need device/driver bind because we need to call dma_configure() which
> >> internally doing iommus sID parsing.
> >
> > I can see some drivers calling of_dma_configure() directly:
> > https://elixir.bootlin.com/linux/latest/ident/of_dma_configure
> >
> > I'm not sure if it's more elegant, but should at least require less code.
>
> I think that in this case of non-TZ where we do iommu mapping by hand we
> can use shared-dma-pool reserved memory see how venus_boot has been
> implemented in the beginning [1].

I might have misunderstood something, but wasn't the shared-dma-pool
about reserving physical memory, while the venus firmware problem is
about reserving certain range of IOVA?

>
> Arnd what do you think?
>
> Some background, we have a use-case where the memory for firmware needs
> to be mapped by the venus driver by hand instead of TZ firmware calls.
> I.e. we want to support both, iommu mapping from the driver and mapping
> done by TZ firmware. How we will differentiate what mapping (TZ or
> non-TZ) will be used is a separate issue.
>
> >
> > By the way, can we really assume that probe of firmware platform
> > device really completes before we call venus_boot()?
>
> I'd say we cannot.

Looking at current implementation in driver core,
of_platform_populate() would actually trigger a synchronous probe, so
I guess it could work. However, I'm not sure if this is a general
guarantee here or it's an implementation detail that shouldn't be
relied on.

If we end up really need to have this platform_driver, I guess we
could call platform_driver_probe() after of_platform_populate(),
rather than pre-registering the driver. That seems to be the way to
ensure that the probe is synchronous and we can also check that a
matching device was found by the return value.

Best regards,
Tomasz

^ permalink raw reply

* Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Archit Taneja @ 2018-06-06  5:59 UTC (permalink / raw)
  To: Heiko Stuebner, dri-devel
  Cc: devicetree, boris.brezillon, linux-arm-msm, tomi.valkeinen,
	briannorris, philippe.cornu, nickey.yang, robh+dt, thierry.reding,
	laurent.pinchart, maxime.ripard
In-Reply-To: <12153185.srskHYKlqL@phil>



On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
>> Add binding info for peripherals that support dual-channel DSI. Add
>> corresponding optional bindings for DSI host controllers that may
>> be configured in this mode. Add an example of an I2C controlled
>> device operating in dual-channel DSI mode.
>>
>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> 
> Looks like a great solution for that problem, so
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> 
> As I'm looking into that for my rk3399-scarlet device right now and
> couldn't find this patchset in the kernel yet, is it planned to
> merge or refresh these binding changes or were problems encountered.
> 
> At least an Ack/Review from Rob seems to be missing.
> 

I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.

Archit

> 
> Heiko
> 
>> ---
>> v2:
>> - Specify that clock-master is a boolean property.
>> - Drop/add unit-address and #*-cells where applicable.
>>
>>   .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++++++++++++++++++++++
>>   1 file changed, 80 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>> index 94fb72cb916f..7a3abbedb3fa 100644
>> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>> @@ -29,6 +29,13 @@ Required properties:
>>   - #size-cells: Should be 0. There are cases where it makes sense to use a
>>     different value here. See below.
>>   
>> +Optional properties:
>> +- clock-master: boolean. Should be enabled if the host is being used in
>> +  conjunction with another DSI host to drive the same peripheral. Hardware
>> +  supporting such a configuration generally requires the data on both the busses
>> +  to be driven by the same clock. Only the DSI host instance controlling this
>> +  clock should contain this property.
>> +
>>   DSI peripheral
>>   ==============
>>   
>> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus (mostly for the data
>>   path). Connections between such peripherals and a DSI host can be represented
>>   using the graph bindings [1], [2].
>>   
>> +Peripherals that support dual channel DSI
>> +-----------------------------------------
>> +
>> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
>> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
>> +left/right half of each line of the display, or even/odd lines of the display).
>> +The graph bindings should be used to represent the multiple DSI busses that are
>> +connected to this peripheral. Each DSI host's output endpoint can be linked to
>> +an input endpoint of the DSI peripheral.
>> +
>>   [1] Documentation/devicetree/bindings/graph.txt
>>   [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>>   
>> @@ -71,6 +88,8 @@ Examples
>>     with different virtual channel configurations.
>>   - (4) is an example of a peripheral on a I2C control bus connected with to
>>     a DSI host using of-graph bindings.
>> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
>> +  which uses I2C as its primary control bus.
>>   
>>   1)
>>   	dsi-host {
>> @@ -153,3 +172,64 @@ Examples
>>   			};
>>   		};
>>   	};
>> +
>> +5)
>> +	i2c-host {
>> +		dsi-bridge@35 {
>> +			compatible = "...";
>> +			reg = <0x35>;
>> +
>> +			ports {
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +
>> +				port@0 {
>> +					reg = <0>;
>> +					dsi0_in: endpoint {
>> +						remote-endpoint = <&dsi0_out>;
>> +					};
>> +				};
>> +
>> +				port@1 {
>> +					reg = <1>;
>> +					dsi1_in: endpoint {
>> +						remote-endpoint = <&dsi1_out>;
>> +					};
>> +				};
>> +			};
>> +		};
>> +	};
>> +
>> +	dsi0-host {
>> +		...
>> +
>> +		/*
>> +		 * this DSI instance drives the clock for both the host
>> +		 * controllers
>> +		 */
>> +		clock-master;
>> +
>> +		ports {
>> +			...
>> +
>> +			port {
>> +				dsi0_out: endpoint {
>> +					remote-endpoint = <&dsi0_in>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +
>> +	dsi1-host {
>> +		...
>> +
>> +		ports {
>> +			...
>> +
>> +			port {
>> +				dsi1_out: endpoint {
>> +					remote-endpoint = <&dsi1_in>;
>> +				};
>> +			};
>> +		};
>> +	};
>>
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver
From: Viresh Kumar @ 2018-06-06  6:01 UTC (permalink / raw)
  To: Taniya Das
  Cc: Rafael J. Wysocki, linux-kernel, linux-pm, Stephen Boyd, robh,
	Rajendra Nayak, devicetree, skannan
In-Reply-To: <1528109194-16864-3-git-send-email-tdas@codeaurora.org>

On 04-06-18, 16:16, Taniya Das wrote:
> The CPUfreq FW present in some QCOM chipsets offloads the steps necessary
> for changing the frequency of CPUs. The driver implements the cpufreq
> driver interface for this firmware.
> 
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
>  drivers/cpufreq/Kconfig.arm       |   9 ++
>  drivers/cpufreq/Makefile          |   1 +
>  drivers/cpufreq/qcom-cpufreq-fw.c | 316 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/cpufreq/qcom-cpufreq-fw.c
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index c7ce928..82c391e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -312,3 +312,12 @@ config ARM_PXA2xx_CPUFREQ
>  	  This add the CPUFreq driver support for Intel PXA2xx SOCs.
> 
>  	  If in doubt, say N.
> +
> +config ARM_QCOM_CPUFREQ_FW
> +	bool "QCOM CPUFreq FW driver"
> +	help
> +	 Support for the CPUFreq FW driver.
> +	 The CPUfreq FW preset in some QCOM chipsets offloads the steps
> +	 necessary for changing the frequency of CPUs. The driver
> +	 implements the cpufreq driver interface for this firmware.
> +	 Say Y if you want to support CPUFreq FW.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index fb4a2ec..34691a2 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -86,6 +86,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)	+= tegra124-cpufreq.o
>  obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)	+= tegra186-cpufreq.o
>  obj-$(CONFIG_ARM_TI_CPUFREQ)		+= ti-cpufreq.o
>  obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)	+= vexpress-spc-cpufreq.o
> +obj-$(CONFIG_ARM_QCOM_CPUFREQ_FW)	+= qcom-cpufreq-fw.o
> 
> 
>  ##################################################################################
> diff --git a/drivers/cpufreq/qcom-cpufreq-fw.c b/drivers/cpufreq/qcom-cpufreq-fw.c
> new file mode 100644
> index 0000000..2135a08
> --- /dev/null
> +++ b/drivers/cpufreq/qcom-cpufreq-fw.c
> @@ -0,0 +1,316 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/cpufreq.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +
> +#define INIT_RATE			300000000UL
> +#define XO_RATE				19200000UL
> +#define LUT_MAX_ENTRIES			40U
> +#define CORE_COUNT_VAL(val)		(((val) & (GENMASK(18, 16))) >> 16)
> +#define LUT_ROW_SIZE			32
> +
> +struct cpufreq_qcom {
> +	struct cpufreq_frequency_table *table;
> +	struct device *dev;
> +	void __iomem *perf_base;
> +	void __iomem *lut_base;
> +	cpumask_t related_cpus;
> +	unsigned int max_cores;
> +};
> +
> +static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
> +
> +static int
> +qcom_cpufreq_fw_target_index(struct cpufreq_policy *policy,
> +			     unsigned int index)
> +{
> +	struct cpufreq_qcom *c = policy->driver_data;
> +
> +	writel_relaxed(index, c->perf_base);
> +
> +	return 0;
> +}
> +
> +static unsigned int qcom_cpufreq_fw_get(unsigned int cpu)
> +{
> +	struct cpufreq_qcom *c;
> +	unsigned int index;
> +
> +	c = qcom_freq_domain_map[cpu];
> +	if (!c)
> +		return 0;
> +
> +	index = readl_relaxed(c->perf_base);
> +	index = min(index, LUT_MAX_ENTRIES - 1);
> +
> +	return c->table[index].frequency;
> +}
> +
> +static int qcom_cpufreq_fw_cpu_init(struct cpufreq_policy *policy)
> +{
> +	struct cpufreq_qcom *c;
> +
> +	c = qcom_freq_domain_map[policy->cpu];
> +	if (!c) {
> +		pr_err("No scaling support for CPU%d\n", policy->cpu);
> +		return -ENODEV;
> +	}
> +
> +	cpumask_copy(policy->cpus, &c->related_cpus);
> +
> +	policy->freq_table = c->table;
> +	policy->driver_data = c;

What about fast cpufreq switching ? I think you can enable that option as well
here..

> +
> +	return 0;
> +}
> +
> +static struct freq_attr *qcom_cpufreq_fw_attr[] = {
> +	&cpufreq_freq_attr_scaling_available_freqs,
> +	&cpufreq_freq_attr_scaling_boost_freqs,
> +	NULL
> +};
> +
> +static struct cpufreq_driver cpufreq_qcom_fw_driver = {
> +	.flags		= CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> +			  CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
> +	.verify		= cpufreq_generic_frequency_table_verify,
> +	.target_index	= qcom_cpufreq_fw_target_index,
> +	.get		= qcom_cpufreq_fw_get,
> +	.init		= qcom_cpufreq_fw_cpu_init,

What about CPU hotplug ? We can still do that, right ? So what will happen if
all CPUs of a freq-domain are removed (hence cpufreq policy is removed) and then
someone calls qcom_cpufreq_fw_get() ? You should really work on cpufreq_policy
there to get 'c'.

> +	.name		= "qcom-cpufreq-fw",
> +	.attr		= qcom_cpufreq_fw_attr,
> +	.boost_enabled	= true,
> +};
> +
> +static int qcom_read_lut(struct platform_device *pdev,
> +			 struct cpufreq_qcom *c)
> +{
> +	struct device *dev = &pdev->dev;
> +	u32 data, src, lval, i, core_count, prev_cc, prev_freq, cur_freq;
> +
> +	c->table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1,
> +				sizeof(*c->table), GFP_KERNEL);
> +	if (!c->table)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> +		data = readl_relaxed(c->lut_base + i * LUT_ROW_SIZE);
> +		src = ((data & GENMASK(31, 30)) >> 30);
> +		lval = (data & GENMASK(7, 0));
> +		core_count = CORE_COUNT_VAL(data);
> +
> +		if (!src)
> +			c->table[i].frequency = INIT_RATE / 1000;
> +		else
> +			c->table[i].frequency = XO_RATE * lval / 1000;
> +
> +		cur_freq = c->table[i].frequency;
> +
> +		dev_dbg(dev, "index=%d freq=%d, core_count %d\n",
> +			i, c->table[i].frequency, core_count);
> +
> +		if (core_count != c->max_cores)
> +			cur_freq = CPUFREQ_ENTRY_INVALID;
> +
> +		/*
> +		 * Two of the same frequencies with the same core counts means
> +		 * end of table.
> +		 */
> +		if (i > 0 && c->table[i - 1].frequency ==
> +		   c->table[i].frequency && prev_cc == core_count) {
> +			struct cpufreq_frequency_table *prev = &c->table[i - 1];
> +
> +			if (prev_freq == CPUFREQ_ENTRY_INVALID)
> +				prev->flags = CPUFREQ_BOOST_FREQ;
> +			break;
> +		}
> +		prev_cc = core_count;
> +		prev_freq = cur_freq;
> +	}
> +
> +	c->table[i].frequency = CPUFREQ_TABLE_END;
> +
> +	return 0;
> +}

Looks like there are many problems here.
- You are assigning prev_freq with cur_freq (which may be uninitialized local
  variable here).
- In this version, you never write CPUFREQ_ENTRY_INVALID to table[i].frequency,
  which looks wrong as well.

> +
> +static int qcom_get_related_cpus(struct device_node *np, struct cpumask *m)
> +{
> +	struct device_node  *cpu_dev;

s/cpu_dev/cpu_np/

> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		cpu_dev = of_cpu_device_node_get(cpu);
> +		if (!cpu_dev)
> +			continue;
> +		cpu_dev = of_parse_phandle(cpu_dev, "qcom,freq-domain", 0);

What's returned here is a pointer to the qcom,freq-domain node, and you assign
that to a variable named cpu_dev. Either use two variables for different node
types, or rename it to temp_np or something similar.

> +		if (!cpu_dev)
> +			continue;
> +		if (cpu_dev == np)
> +			cpumask_set_cpu(cpu, m);
> +	}
> +
> +	if (cpumask_empty(m))
> +		return -ENOENT;
> +
> +	return 0;
> +}
> +
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +				   struct device_node *np)
> +{
> +	struct cpufreq_qcom *c;
> +	struct resource res;
> +	struct device *dev = &pdev->dev;
> +	void __iomem *en_base;
> +	int cpu, index, ret;
> +
> +	c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
> +	if (!c)
> +		return -ENOMEM;
> +
> +	index = of_property_match_string(np, "reg-names", "enable");
> +	if (index < 0)
> +		return index;
> +
> +	if (of_address_to_resource(np, index, &res))
> +		return -ENOMEM;
> +
> +	en_base = devm_ioremap(dev, res.start, resource_size(&res));
> +	if (!en_base) {
> +		dev_err(dev, "Unable to map %s enable-base\n", np->name);
> +		return -ENOMEM;
> +	}
> +
> +	/* FW should be in enabled state to proceed */
> +	if (!(readl_relaxed(en_base) & 0x1)) {
> +		dev_err(dev, "%s firmware not enabled\n", np->name);
> +		return -ENODEV;
> +	}
> +	devm_iounmap(&pdev->dev, en_base);
> +
> +	index = of_property_match_string(np, "reg-names", "perf");
> +	if (index < 0)
> +		return index;
> +
> +	if (of_address_to_resource(np, index, &res))
> +		return -ENOMEM;
> +
> +	c->perf_base = devm_ioremap(dev, res.start, resource_size(&res));
> +	if (!c->perf_base) {
> +		dev_err(dev, "Unable to map %s perf-base\n", np->name);
> +		return -ENOMEM;
> +	}
> +
> +	index = of_property_match_string(np, "reg-names", "lut");
> +	if (index < 0)
> +		return index;
> +
> +	if (of_address_to_resource(np, index, &res))
> +		return -ENOMEM;
> +
> +	c->lut_base = devm_ioremap(dev, res.start, resource_size(&res));
> +	if (!c->lut_base) {
> +		dev_err(dev, "Unable to map %s lut-base\n", np->name);
> +		return -ENOMEM;
> +	}
> +
> +	ret = qcom_get_related_cpus(np, &c->related_cpus);
> +	if (ret) {
> +		dev_err(dev, "%s failed to get core phandles\n", np->name);

Maybe write a more relevant error message here ?

> +		return ret;
> +	}
> +
> +	c->max_cores = cpumask_weight(&c->related_cpus);

Maybe remove the error checking conditional from qcom_get_related_cpus() and
check !c->max_cores here for the same.

> +
> +	ret = qcom_read_lut(pdev, c);
> +	if (ret) {
> +		dev_err(dev, "%s failed to read LUT\n", np->name);
> +		return ret;
> +	}

Enter a blank line here.

> +	for_each_cpu(cpu, &c->related_cpus)
> +		qcom_freq_domain_map[cpu] = c;

This whole setup looks a bit confusing to me. This is what you are doing
essentially:

qcom_resources_init()
{
        for_each_possible_cpu() {
                qcom_cpu_resources_init()
                {
                        populate c->related_cpus;

                        for_each_related_cpu() {
                                qcom_freq_domain_map[cpu] = c;
                        }
                }
        }
}

So if there are 4 CPUs that share a freq domain, then you are allocating 'c' 4
times and (over)writing qcom_freq_domain_map[] for all these CPUs 4 times and
finally keeping value of 'c' only once.

You must be running most of the work done in qcom_resources_init() only once per
freq-domain.

> +
> +	return 0;
> +}
> +
> +static int qcom_resources_init(struct platform_device *pdev)
> +{
> +	struct device_node *np, *cpu_dev;

cpu_dev is normally used in kernel for struct device *, maybe use cpu_np ?

> +	unsigned int cpu;
> +	int ret;
> +
> +	for_each_possible_cpu(cpu) {
> +		cpu_dev = of_cpu_device_node_get(cpu);
> +		if (!cpu_dev) {
> +			dev_err(&pdev->dev, "Failed to get cpu %d device\n",
> +				cpu);
> +			continue;
> +		}
> +
> +		np = of_parse_phandle(cpu_dev, "qcom,freq-domain", 0);
> +		if (!np) {
> +			dev_err(&pdev->dev, "Failed to get freq-domain device\n");
> +			continue;

I am not sure if we should continue or error out here. Why would you want only a
group of CPUs to have this property set ? Or if you really have a case for that
currently ?

> +		}
> +
> +		of_node_put(cpu_dev);
> +
> +		ret = qcom_cpu_resources_init(pdev, np);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int qcom_cpufreq_fw_driver_probe(struct platform_device *pdev)
> +{
> +	int rc;
> +
> +	/* Get the bases of cpufreq for domains */
> +	rc = qcom_resources_init(pdev);
> +	if (rc) {
> +		dev_err(&pdev->dev, "CPUFreq resource init failed\n");
> +		return rc;
> +	}
> +
> +	rc = cpufreq_register_driver(&cpufreq_qcom_fw_driver);
> +	if (rc) {
> +		dev_err(&pdev->dev, "CPUFreq FW driver failed to register\n");
> +		return rc;
> +	}
> +
> +	dev_info(&pdev->dev, "QCOM CPUFreq FW driver inited\n");

s/inited/initialized/ ?

> +
> +	return 0;
> +}
> +
> +static const struct of_device_id match_table[] = {
> +	{ .compatible = "qcom,cpufreq-fw" },
> +	{}
> +};
> +
> +static struct platform_driver qcom_cpufreq_fw_driver = {
> +	.probe = qcom_cpufreq_fw_driver_probe,
> +	.driver = {
> +		.name = "qcom-cpufreq-fw",
> +		.of_match_table = match_table,
> +		.owner = THIS_MODULE,
> +	},
> +};
> +
> +static int __init qcom_cpufreq_fw_init(void)
> +{
> +	return platform_driver_register(&qcom_cpufreq_fw_driver);
> +}
> +subsys_initcall(qcom_cpufreq_fw_init);
> +
> +MODULE_DESCRIPTION("QCOM CPU Frequency FW");
> +MODULE_LICENSE("GPL v2");
> --
> Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
> of the Code Aurora Forum, hosted by the  Linux Foundation.

-- 
viresh

^ permalink raw reply

* [PATCH v3 0/6] Add MCAN Support for dra76x
From: Faiz Abbas @ 2018-06-06  6:08 UTC (permalink / raw)
  To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
  Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas, mark.rutland

The following patches add dts and sysconfig support
for MCAN on TI's dra76 SOCs

The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/

Changes in v3:
 1. Added reset functionality to the ti-sysc
    driver. This enables me to drop the hwmod
    data patch as everything is being done in dt.

 2. Dropped ti,hwmods from the dts nodes

 3. Fixed the unit address of target-module
    and mcan

 4. Removed the status="disabled" in dtsi
    followed by status="okay" in dts.

Changes in v2:
 1. Added Support for mcan in the ti-sysc driver
    Also added the target-module node for the same

 2. Added clkctrl data for mcan clocks

Faiz Abbas (4):
  clk: ti: dra7: Add clkctrl clock data for the mcan clocks
  bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
  bus: ti-sysc: Add support for software reset
  ARM: dts: Add generic interconnect target module node for MCAN

Franklin S Cooper Jr (1):
  ARM: dts: dra76x: Add MCAN node

Lokesh Vutla (1):
  ARM: dts: dra762: Add MCAN clock support

 .../devicetree/bindings/bus/ti-sysc.txt       |  1 +
 arch/arm/boot/dts/dra76-evm.dts               |  6 ++
 arch/arm/boot/dts/dra76x.dtsi                 | 65 +++++++++++++++++++
 drivers/bus/ti-sysc.c                         | 58 +++++++++++++++++
 drivers/clk/ti/clk-7xx.c                      |  1 +
 include/dt-bindings/bus/ti-sysc.h             |  2 +
 include/dt-bindings/clock/dra7.h              |  1 +
 include/linux/platform_data/ti-sysc.h         |  1 +
 8 files changed, 135 insertions(+)

-- 
2.17.0

^ permalink raw reply

* [PATCH v3 1/6] ARM: dts: dra762: Add MCAN clock support
From: Faiz Abbas @ 2018-06-06  6:08 UTC (permalink / raw)
  To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
  Cc: mark.rutland, paul, tony, faiz_abbas, t-kristo, robh+dt, bcousson
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>

From: Lokesh Vutla <lokeshvutla@ti.com>

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
 	ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+	dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&dpll_gmac_x2_ck>;
+		ti,max-div = <63>;
+		reg = <0x03fc>;
+		ti,bit-shift=<20>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+		assigned-clock-rates = <80000000>;
+	};
+
+	dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+		reg = <0x3fc>;
+		ti,bit-shift = <29>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+	};
+
+	mcan_clk: mcan_clk@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		ti,bit-shift = <27>;
+		reg = <0x3fc>;
+	};
+};
-- 
2.17.0

^ permalink raw reply related

* [PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-06-06  6:08 UTC (permalink / raw)
  To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
  Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas, mark.rutland
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>

Add clkctrl data for the m_can clocks and register it within the
clkctrl driver

CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/clk/ti/clk-7xx.c         | 1 +
 include/dt-bindings/clock/dra7.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index fb249a1637a5..71a122b2dc67 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
 	{ DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
 	{ DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
 	{ DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
+	{ DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk"},
 	{ 0 },
 };
 
diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
index 5e1061b15aed..d7549c57cac3 100644
--- a/include/dt-bindings/clock/dra7.h
+++ b/include/dt-bindings/clock/dra7.h
@@ -168,5 +168,6 @@
 #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
 #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
 #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
+#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
 
 #endif
-- 
2.17.0

^ 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