Re: [PATCH v6 1/6] arm/arm64: add smccc

[Mark Rutland]

> > > +/*
> > > + * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
> > > + * unsigned long a3, unsigned long a4, unsigned long a5,
> > > + * unsigned long a6, unsigned long a7, struct smccc_res 
> > > *res)
> > > + */
> > > +ENTRY(smccc_smc)
> > > + smc #0
> > > + ldr x4, [sp]
> > > + stp x0, x1, [x4, #SMC_RES_X0_OFFS]
> > > + stp x2, x3, [x4, #SMC_RES_X2_OFFS]
> > > + ret
> > > +ENDPROC(smccc_smc)

> > > +/*
> > > + * void smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
> > > + * unsigned long a3, unsigned long a4, unsigned long a5,
> > > + * unsigned long a6, unsigned long a7, struct smccc_res 
> > > *res)
> > > + */
> > > +ENTRY(smccc_hvc)
> > > + hvc #0
> > > + ldr x4, [sp]
> > > + stp x0, x1, [x4, #SMC_RES_X0_OFFS]
> > > + stp x2, x3, [x4, #SMC_RES_X2_OFFS]
> > > + ret
> > > +ENDPROC(smccc_hvc)

> > > +/**
> > > + * struct smccc_res - Result from SMC/HVC call
> > > + * @a0-a3 result values from registers 0 to 3
> > > + */
> > > +struct smccc_res {
> > > + unsigned long a0;
> > > + unsigned long a1;
> > > + unsigned long a2;
> > > + unsigned long a3;
> > > +};
> > 
> > Are there any endianness considerations for this structure?
> 
> No, I can't find anything in the ARM SMC Calling Convention document
> indicating that.

The calling conventions have no bearing on the structure, which is our
invention.

We stash register values (which don't have endianness) returned by the
firmeware into the structure in the sequences above (which appear
endian-clean to me).

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/6] arm/arm64: add smccc

[Will Deacon]

On Mon, Nov 02, 2015 at 02:03:13PM +, Mark Rutland wrote:
> > > > +/**
> > > > + * struct smccc_res - Result from SMC/HVC call
> > > > + * @a0-a3 result values from registers 0 to 3
> > > > + */
> > > > +struct smccc_res {
> > > > +   unsigned long a0;
> > > > +   unsigned long a1;
> > > > +   unsigned long a2;
> > > > +   unsigned long a3;
> > > > +};
> > > 
> > > Are there any endianness considerations for this structure?
> > 
> > No, I can't find anything in the ARM SMC Calling Convention document
> > indicating that.
> 
> The calling conventions have no bearing on the structure, which is our
> invention.
> 
> We stash register values (which don't have endianness) returned by the
> firmeware into the structure in the sequences above (which appear
> endian-clean to me).

Ah yes, the structure is populated by the kernel not the firmware, so
there's nothing to worry about. Thanks for the explanation.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 02/16] Documentation: dt-bindings: backlight: add TI LMU backlight binding information

[Rob Herring]

On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim  wrote:
> LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
> for describing device.
>
> Cc: devicetree@vger.kernel.org
> Cc: Jingoo Han 
> Cc: Lee Jones 
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Milo Kim 
> ---
>  .../bindings/video/backlight/ti-lmu-backlight.txt  | 67 
> ++

Please move to bindings/leds/backlight/

>  1 file changed, 67 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt 
> b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
> new file mode 100644
> index 000..27b0036
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
> @@ -0,0 +1,67 @@
> +TI LMU backlight device tree bindings
> +
> +Required properties:
> +  - compatible: Should be one of lists below.
> +"ti,lm3532-backlight"
> +"ti,lm3631-backlight"
> +"ti,lm3632-backlight"
> +"ti,lm3633-backlight"
> +"ti,lm3695-backlight"
> +"ti,lm3697-backlight"
> +
> +Optional properties:
> +  There are two backlight control mode. One is I2C, the other is PWM mode.
> +  Following properties are only specified in PWM mode.
> +  Please note that LMU backlight device can have only one PWM channel.
> +
> +  - pwms: OF device-tree PWM specification.
> +  - pwm-names: a list of names for the PWM devices specified in the "pwms"
> +   property.
> +
> +  For the PWM user nodes, please refer to [1].
> +
> +Child nodes:
> +  LMU backlight is represented as sub-nodes of the TI LMU device [2].
> +  So, LMU backlight should have more than one backlight child node.
> +  Each node exactly matches with backlight control bank configuration.
> +  Maximum numbers of child nodes depend on the device.
> +  1 = LM3631, LM3632, LM3695
> +  2 = LM3633, LM3697
> +  3 = LM3532
> +
> +  Required property of a child node:
> +  - hvled1-used, hvled2-used, hvled3-used:
> +High voltage backlight strings configuration. Type is .
> +Please describe which output backlight string is used.
> +Please refer to the datasheets [3].

Use led-sources.

> +
> +  Optional properties of a child node:
> +  - backlight-name: Name string for backlight device identification.
> +It is used for creating backlight sysfs,
> +/sys/class/backlight//.

Use label.

> +  - backlight-max-microamp: Max current setting. Type is .
> +Unit is microampere.
> +Range is from 5000 to 3.

Use led-max-microamp

> +  - initial-brightness: Backlight initial brightness value. Type is .
> +It is set as soon as backlight device is created.
> +0 ~ 2047 = LM3631, LM3632, LM3633, LM3695 and LM3697
> +0 ~ 255  = LM3532

Use default-brightness-level

> +  - ramp-up-msec, ramp-down-msec: Light dimming effect properties.
> +  Type is . Unit is millisecond.
> +  0 ~ 65 msec= LM3532
> +  0 ~ 4000 msec  = LM3631
> +  0 ~ 16000 msec = LM3633 and LM3697
> +  - pwm-period: PWM period. Only valid in PWM brightness mode.
> +Type is . If this property is missing, then control
> +mode is set to I2C by default.
> +
> +Examples: Please refer to ti-lmu dt-bindings. [2].
> +
> +[1] Documentation/devicetree/bindings/pwm/pwm.txt
> +[2] Documentation/devicetree/bindings/mfd/ti-lmu.txt
> +[3] LM3532: http://www.ti.com/product/LM3532/datasheet
> +LM3631: http://www.ti.com/product/LM3631/datasheet
> +LM3632: http://www.ti.com/product/LM3632A/datasheet
> +LM3633: http://www.ti.com/product/LM3633/datasheet
> +LM3695: Datasheet is not opened yet, but only two strings are used.
> +LM3697: http://www.ti.com/product/LM3697/datasheet
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

[Rob Herring]

On Mon, Nov 2, 2015 at 3:13 AM, Zain  wrote:
> Hi Mark
>
> On 2015年10月30日 22:03, Mark Rutland wrote:
>> On Fri, Oct 30, 2015 at 04:22:49PM +0800, Zain Wang wrote:
>>> Add DT bindings documentation for the rk3288 crypto drivers.
>>>
>>> Signed-off-by: Zain Wang 
>>> ---

>>> +Required properties:
>>> +- compatible: should be "rockchip,crypto"
>> Choose a more specific name. Rockchip could easily come up with another
>> crypto accelerator later.
> ok! done.
> rk3288_crypto may be better than crypto.

Yes, but use '-' not '_'.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dt-bindings: gpio: Documentation for Hi6220 gpio driver

[Rob Herring]

On Fri, Oct 30, 2015 at 9:24 PM, Zhong Kaihua  wrote:
> dt-bindings: gpio: Documentation for Hi6220 gpio driver
>
> Signed-off-by: Zhong Kaihua 
> ---
>  .../devicetree/bindings/gpio/gpio-hi6220.txt   | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
> new file mode 100644
> index 000..76a8932
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
> @@ -0,0 +1,23 @@
> +Hisilicon Hi6220 GPIO controller bindings
> +
> +Required properties:
> +  - compatible:"arm,pl061", "arm,primecell"
> +  - gpio-controller: Marks the device node as aGPIO controller.
> +  - #gpio-cells: Shouldbe 2. See gpio.txt in this directory for a

Some strange spacing in here. Otherwise,

Acked-by: Rob Herring 

> +description of the cells format.
> +  - interrupt-controller: Mark the device node as an interrupt controller
> +
> +Example:
> +
> +   gpio0: gpio@f8011000 {
> +   compatible = "arm,pl061", "arm,primecell";
> +   reg = <0x0 0xf8011000 0x0 0x1000>;
> +   interrupts = <0 52 0x4>;
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   clocks = <_ctrl 2>;
> +   clock-names = "apb_pclk";
> +   status = "ok";
> +   };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Rob Herring]

On Mon, Nov 2, 2015 at 12:07 AM, Sinan Kaya  wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design. The management
> driver is executed in hypervisor context and is the main
> management entity for all channels provided by the device.
> The channel driver is executed in the hypervisor/guest OS
> context.
>
> All channel devices get probed in the hypervisor
> context during power up. They show up as DMA engine
> channels. Then, before starting the virtualization; each
> channel device is unbound from the hypervisor by VFIO
> and assigned to the guest machine for control.
>
> This management driver will be used by the system
> admin to monitor/reset the execution state of the DMA
> channels. This will be the management interface.
>
> Signed-off-by: Sinan Kaya 
> ---
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  56 ++
>  drivers/dma/Kconfig|  11 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/qcom_hidma_mgmt.c  | 747 
> +
>  4 files changed, 815 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>  create mode 100644 drivers/dma/qcom_hidma_mgmt.c
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
> b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> new file mode 100644
> index 000..514d37d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -0,0 +1,56 @@
> +Qualcomm Technologies HIDMA Management interface
> +
> +The Qualcomm Technologies HIDMA device has been designed
> +to support virtualization technology. The driver has been
> +divided into two to follow the hardware design. The management
> +driver is executed in hypervisor context and is the main
> +management entity for all channels provided by the device.
> +The channel driver is executed in the hypervisor/guest OS
> +context.

This doesn't really explain what the block is.

> +All channel devices get probed in the hypervisor
> +context during power up. They show up as DMA engine
> +DMA channels. Then, before starting the virtualization; each
> +channel device is unbound from the hypervisor by VFIO
> +and assign to the guest machine for control.
> +
> +This management driver will  be used by the system
> +admin to monitor/reset the execution state of the DMA
> +channels. This will be the management interface.
> +
> +
> +Required properties:
> +- compatible: must contain "qcom,hidma-mgmt"

Please make this more specific. It doesn't match your example either.
Unless "1.0" type versioning is tightly controlled and defined,
version numbers are usually not a good practice.

> +- reg: Address range for DMA device
> +- dma-channels: Number of channels supported by this DMA controller.
> +- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
> +  fragmented to multiples of this amount.
> +- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
> +  fragmented to multiples of this amount.
> +- max-write-transactions: Maximum write transactions to perform in a burst
> +- max-read-transactions: Maximum read transactions to perform in a burst

This would be a function of burst-bytes and bus width. Are you sure
you don't me number of outstanding transactions which is a common
parameter for AXI bus peripherals.

> +- channel-reset-timeout: Channel reset timeout for this SOC.

Please add units to property name.

> +- channel-priority: Priority of the channel.
> +  Each dma channel share the same HW bandwidth with other dma channels.
> +  If two requests reach to the HW at the same time from a low priority and
> +  high priority channel, high priority channel will claim the bus.
> +  0=low priority, 1=high priority
> +- channel-weight: Round robin weight of the channel
> +  Since there are only two priority levels supported, scheduling among
> +  the equal priority channels is done via weights.
> +
> +Example:
> +
> +   hidma-mgmt@f9984000 = {
> +   compatible = "qcom,hidma-mgmt-1.0";
> +   reg = <0xf9984000 0x15000>;
> +   dma-channels = 6;
> +   max-write-burst-bytes = 1024;
> +   max-read-burst-bytes = 1024;
> +   max-write-transactions = 31;
> +   max-read-transactions = 31;
> +   channel-reset-timeout = 0x500;
> +   channel-priority = < 1 1 0 0 0 0>;
> +   channel-weight = < 1 13 10 3 4 5>;
> +   };
> +
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Peter Ujfalusi]

Vinod,

On 11/02/2015 05:40 PM, Vinod Koul wrote:
> On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote:
>> Vinod,
>>
>> On 11/02/2015 12:04 PM, Vinod Koul wrote:
>>> On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote:
>>>> Hi,
>>>>
>>>> 1) This seems to have broken BBB in -next for me, bisected down to this 
>>>> patch.
>>>>
>>>> For bootlog:
>>>> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
>>>>
>>>> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
>>>> at least without an ack from the platform maintainer. It can be a a
>>>> huge mess if they end up causing conflicts, so we always ask to merge
>>>> the DT changes through the platform maintainer (Tony in this case) by
>>>> default.
>>>
>>> I did warn when applying that I am doing so without ACK on ARM code, noone
>>> said a thing!
>>>
>>> I knew Tony was following the work by Peter so assumed he must have been 
>>> okay
>>> with it otherwise would have spoken for ~couple of weeks these were in
>>> review
>>>
>>> Anyway now that we have a regression, I can revert this patch if that fixes,
>>> please confirm, but might break edma... peter?
>>
>> Can you revert or drop the last two DTS patches?
>>
>> I think I will try a different route to get the split of the tpcc and tptc.
>> Without the DT patches the driver will fall back to the legacy mode so things
>> will work in a same way they did before.
>> Or I can send a followup patch for edma.c, with that there is no need to add
>> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better.
>> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod
>> code will not shut it down but we will keep the possibility to manage the
>> power state still.
> 
> Okay I have reverted the two and applied the edma patch sent, can you please
> verify topic/edma_fix before I merge it and send my PULL request.

The branch looks good. Thank you!
It would have been great if the DTS changes for am335x/am437x would have been
in 4.4, but I will send them for 4.5 after rc1 is out.

> Would appreciate any tested-by
> 
> Thanks
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v13 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Gabriele Paoloni]

Hi Bjorn

I see this patchset merged into your next branch.

Can you confirm?

Many Thanks

Gab

> -Original Message-
> From: Wangzhou (B)
> Sent: Thursday, October 29, 2015 9:41 AM
> To: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; rmk+ker...@arm.linux.org.uk; thomas.petazzoni@free-
> electrons.com; Gabriele Paoloni; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth);
> Wangzhou (B)
> Subject: [PATCH v13 0/6] PCI: hisi: Add PCIe host support for HiSilicon
> SoC Hip05
> 
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe
> hosts
> use PCIe IP core from Synopsys, So this driver is based on designware
> PCIe driver.
> 
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe
> API in
> designware PCIe driver. So this patch also adds ARM64 support for
> designware
> pcie.
> 
> This patchset is based on v4.3-rc1.
> 
> Change from v12:
> - Reorder patchset as suggestion by Bjorn.
> - Add Rob's Acked-by for DT binding.
> - Merge HiSilicon PCIe driver, DT binding document and maintainer
> update into
>   one patch.
> 
> Change from v11:
> - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.
> - Add print in pcie-hisi.c to indicate read/write hardware defect.
> - Modify macro in 1/8 pointed by Bjorn.
> 
> Change from v10:
> - Remove MSI related setting and VMID/ASID table setting, they will be
>   implemented in BIOS.
> - Use module_platform_driver to init pcie-hisi.c
> - Add necessary comments.
> 
> Change from v9:
> - Use syscon to get subctrl base address.
> - 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02
> board
>   from Ding Tianhong
> - Add hisi_pcie_cfg_read in pcie-hisi.c to match
>   [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and
> dw_pcie_cfg_read()
>   from Gabriele.
> 
> Change from v8:
> - Rebase on v4.3-rc1.
> - Add Tested-by from Gabriel and Minghuan.
> - Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need
> this as PCI
>   core does related job. Add ITS base address parsing in msi_host_init.
> - Change vmid/asid table configuration, previous configuration was
> wrong.
> - Add wr_own_conf callback in pcie-hisi.c.
> - Use subsys_initcall to init hisi PCIe.
> 
> Change from v7:
> - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone,
> layerscape,
>   spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus
> number.
> - Remove bus-range parsing in pcie-hisi.c.
> 
> Change from v6:
> - Add Pratyush's Acked-by for 1/6 and 2/6.
> - Add James' Tested-by for 3/6.
> 
> Change from v5:
> - Merge 1/6 in this series, discussion about this can be found in [1]
> 
> Change from v4:
> - Change the author of 1/5 to Gabriele.
> - Modify problems in 3/5 pointed by Bjorn.
> - Modify spelling problems in 4/5.
> 
> Change from v3:
> - Change 1/5 to what Gabriele suggested.
> - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3
> series.
> 
> Change from v2:
> - Move struct pci_dev *dev and struct pci_sys_data *sys in
>   pcibios_align_resource in 1/5.
> - Add Gabriele's codes in 2/5 which delete unnecessary information
> parse and
>   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
> - Add maintainer patch 5/5.
> 
> Change from RFC v1:
> - Add 1/4 patch by Arnd which removes align_resource callback in ARM
>   pcibios_align_resource.
> - Change head file in pcie-designware from asm/hardirq.h to
> linux/hardirq.h.
> - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx.
> - Remove unnecessary parentheses of some macros in pcie-hisi.
> - Use macro to replace some magic values.
> - Merge two loops together and add some comments about it in
> context_config
>   function in pcie-hisi.
> - Modify some value of items in pcie node example in binding document.
> 
> Change from RFC:
> - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
>   merge related operations into dw_pcie_host_init.
> 
> Link of v12:
> - https://lkml.org/lkml/2015/10/26/196
> Link of v11:
> - https://lkml.org/lkml/2015/10/16/228
> Link of v10:
> - http://www.spinics.net/lists/linux-pci/msg45490.html
> Link of v9:
> - http://www.spinics.net/lists/linux-pci/msg44545.html
> Link of v8:
> - http://www.spinics.net/lists/linux-pci/msg44192.html
> Link of v7:
> - http://www.spinics.net/lists/devicetree/msg90690.html
> Link of v6:
> - http://www.spinics.net/lists/linux-pci/msg43669.html
> Link of v5:
> - http://www.spinics.net/lists/devicetree/msg87959.html
> Link of v4:
> - http://www.spinics.net/lists/arm-kernel/msg433050.html
> Link of v3:
> - http://www.spinics.net/lists/linux-pci/msg42539.html
> Link 

Re: [PATCH] gpio: dt-bindings: document the official use of "ngpios"

[Rob Herring]

On Fri, Oct 30, 2015 at 6:03 AM, Linus Walleij  wrote:
> There are a bunch of drivers that utilize the "ngpios" DT property
> without any vendor prefix. Try to start cleaning up the mess by
> defining what we mean by this property.
>
> Cc: devicetree@vger.kernel.org
> Cc: Pramod Kumar 
> Cc: Jonas Gorski 
> Signed-off-by: Linus Walleij 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/gpio/gpio.txt | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 63b1b9039ce8..9b081e6143a0 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -129,6 +129,30 @@ Every GPIO controller node must contain both an empty 
> "gpio-controller"
>  property, and a #gpio-cells integer property, which indicates the number of
>  cells in a gpio-specifier.
>
> +Optionally, a GPIO controller may have a "ngpios" property. This property
> +indicates the number of in-use slots of available slots for GPIOs. The
> +typical example is something like this: the hardware register is 32 bits
> +wide, but only 18 of the bits have a physical counterpart. The driver is
> +generally written so that all 32 bits can be used, but the IP block is reused
> +in a lot of designs, some using all 32 bits, some using 18 and some using
> +12. In this case, setting "ngpios = <18>;" informs the driver that only the
> +first 18 GPIOs, at local offset 0 .. 17, are in use.
> +
> +If these GPIOs do not happen to be the first N GPIOs at offset 0...N, an
> +additional bitmask is needed to specify which GPIOs are actually in use,
> +and which are dummies. The bindings for this case has not yet been
> +specified, but should be specified if/when such hardware appears.
> +
> +Example:
> +
> +gpio-controller@ {
> +   compatible = "foo";
> +   reg = <0x 0x1000>;
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   ngpios = <18>;
> +}
> +
>  The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
>  providing automatic GPIO request and configuration as part of the
>  gpio-controller's driver probe function.
> --
> 2.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Rob Herring]

On Fri, Oct 30, 2015 at 9:20 PM, Viresh Kumar  wrote:
> On 30-10-15, 15:18, Stephen Boyd wrote:
>> A side-note. I wonder if it would be better style to have the
>> node name be:
>>
>>   opp@6 {
>
> I thought the @... had a special meaning and we might end up creating
> some device for the node then? Perhaps I am mistaken.

There is no special meaning, just convention which is the unit-address
should match the reg property address. I'm okay with an exception
here.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model

[Punit Agrawal]

Viresh Kumar  writes:

> On 22-10-15, 20:02, Dawei Chien wrote:
>> Use Intelligent Power Allocation (IPA) technical to add static/dynamic power 
>> model for binding CPU thermal zone.
>> The power allocator governor allocates power budget to control CPU 
>> temperature.
>> 
>> Power Allocator governor is able to keep SOC temperature within a
>> defined temperature range to avoid SOC overheat and keep it's
>> performance. mt8173-cpufreq.c need to register its' own power model
>> with power allocator thermal governor, so that power allocator
>> governor can allocates suitable power budget to control CPU
>> temperature.
>> 
>> PATCH1 is base on
>> https://patchwork.kernel.org/patch/7034601/
>> 
>> PATCH2 is base on Sascha's thermal driver V9
>> https://patchwork.kernel.org/patch/7249821/
>> https://patchwork.kernel.org/patch/7249861/
>> https://patchwork.kernel.org/patch/7249891/
>> 
>> Change since V1:
>> include mt8171.h and sort header file for mt8173.dtsi
>> 
>> Change since V2:
>> Move dynamic/static power model in device tree
>> 
>> Dawei.Chien (2):
>>   thermal: mediatek: Add cpu power cooling model.
>>   arm64: dts: mt8173: Add thermal zone node for mt8173.
>
> Sorry for being extremely late in reviewing this stuff. You are
> already on v3 and I haven't reviewed it once. Mostly due to bad timing
> of my holidays and other work pressure.
>
> Now, there are few things that I feel are not properly addressed here,
> and I may be wrong:
> - Where are the bindings for static-power-points and
>   dynamic-power-coefficient. Sorry I failed to see them in this or
>   other series you mentioned.

For dynamic power, I had posted some patches[0][1][2] introducing the
binding as well as updating cooling device registration via cpufreq
driver. Now that the SCPI hwmon driver is merged, I should re-send the
remaining patches.

[0] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01020.html
[1] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01022.html
[3] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01031.html

> - Even then, why should we be adding another table into DT for
>   voltage/power ? And not reuse and extend the opp-v2 stuff which is
>   already mainlined now.
> - There are few issues with the code as well, but I want to see where
>   the bindings should go first. And then only discuss the code
>   further.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/6] arm/arm64: add smccc

[Jens Wiklander]

On Mon, Nov 02, 2015 at 11:51:19AM +, Will Deacon wrote:
> Hi Jens,
> 
> On Thu, Oct 29, 2015 at 09:21:23AM +0100, Jens Wiklander wrote:
> > Adds helpers to do SMC and HVC based on ARM SMC Calling Convention.
> > CONFIG_HAVE_SMCCC is enabled for architectures that may support
> > the SMC or HVC instruction. It's the responsibility of the caller
> > to know if the SMC instruction is supported by the platform.
> > 
> > Signed-off-by: Jens Wiklander 
> > ---
> >  arch/arm/Kconfig   |  4 ++
> >  arch/arm/kernel/Makefile   |  2 +
> >  arch/arm/kernel/smccc-call.S   | 49 +
> >  arch/arm/kernel/smccc.c| 18 
> >  arch/arm64/Kconfig |  4 ++
> >  arch/arm64/kernel/Makefile |  1 +
> >  arch/arm64/kernel/smccc-call.S | 43 ++
> >  arch/arm64/kernel/smccc.c  | 18 
> >  include/linux/arm-smccc.h  | 98 
> > ++
> 
> This should probably be split so that the arm and arm64 patches can be
> merged separately.

OK, what's preferable two or three patches?

> 
> >  9 files changed, 237 insertions(+)
> >  create mode 100644 arch/arm/kernel/smccc-call.S
> >  create mode 100644 arch/arm/kernel/smccc.c
> >  create mode 100644 arch/arm64/kernel/smccc-call.S
> >  create mode 100644 arch/arm64/kernel/smccc.c
> >  create mode 100644 include/linux/arm-smccc.h
> 
> [...]
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 72ad724..29ab16a 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -226,6 +226,9 @@ config NEED_RET_TO_USER
> >  config ARCH_MTD_XIP
> > bool
> >  
> > +config HAVE_SMCCC
> > +   bool
> 
> If you want this to be selectable by multiple arches, wouldn't it be
> better to define it out in a common Kconfig file? Maybe HAVE_ARM_SMCCC
> too, for some better namespacing.

What's a good place, init/Kconfig?

> 
> An alternative is just making your TEE driver depend on ARM || ARM64
> and providing dummy smc wrappers that return an error code for cores
> older than ARMv7.

It's tempting, but it would mean adding this dummy function for all
architectures as it need to be exported to be usable from a load module.

> 
> > diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> > new file mode 100644
> > index 000..9098bd8
> > --- /dev/null
> > +++ b/arch/arm64/kernel/smccc-call.S
> > @@ -0,0 +1,43 @@
> > +/*
> > + * Copyright (c) 2015, Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License Version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +#include 
> > +
> > +#define SMC_RES_X0_OFFS0
> > +#define SMC_RES_X2_OFFS16
> 
> These should be generates in asm-offsets.c

OK

> 
> > +
> > +/*
> > + * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
> > + *   unsigned long a3, unsigned long a4, unsigned long a5,
> > + *   unsigned long a6, unsigned long a7, struct smccc_res *res)
> > + */
> > +ENTRY(smccc_smc)
> > +   smc #0
> > +   ldr x4, [sp]
> > +   stp x0, x1, [x4, #SMC_RES_X0_OFFS]
> > +   stp x2, x3, [x4, #SMC_RES_X2_OFFS]
> > +   ret
> > +ENDPROC(smccc_smc)
> > +
> > +/*
> > + * void smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
> > + *   unsigned long a3, unsigned long a4, unsigned long a5,
> > + *   unsigned long a6, unsigned long a7, struct smccc_res *res)
> > + */
> > +ENTRY(smccc_hvc)
> > +   hvc #0
> > +   ldr x4, [sp]
> > +   stp x0, x1, [x4, #SMC_RES_X0_OFFS]
> > +   stp x2, x3, [x4, #SMC_RES_X2_OFFS]
> > +   ret
> > +ENDPROC(smccc_hvc)
> 
> Maybe you could generate both of these from an asm macro that takes the
> first instruction as a parameter?

OK

> 
> > diff --git a/arch/arm64/kernel/smccc.c b/arch/arm64/kernel/smccc.c
> > new file mode 100644
> > index 000..ed13ba3
> > --- /dev/null
> > +++ b/arch/arm64/kernel/smccc.c
> > @@ -0,0 +1,18 @@
> > +/*
> > + * Copyright (c) 2015, Linaro Limited
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +#include 
> > +#include 
> > +
> > +EXPORT_SYMBOL_GPL(smccc_smc);
> > 

Re: [PATCH v2 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Rob Herring]

On Fri, Oct 30, 2015 at 5:34 PM, Bjorn Andersson
 wrote:
> From: Werner Johansson 
>
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 

Acked-by: Rob Herring 

> ---
>
> Change since v1:
> - Dropped -vid suffix from compatible
>
>  .../bindings/display/panel/sharp,ls043t1le01.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt 
> b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
> new file mode 100644
> index ..b3d4e073930a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
> @@ -0,0 +1,22 @@
> +Sharp Microelectronics 4.3" qHD TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls043t1le01-qhd"
> +- reg: DSI virtual channel of the peripheral
> +- power-supply: phandle of the regulator that provides the supply voltage
> +
> +Optional properties:
> +- backlight: phandle of the backlight device attached to the panel
> +- reset-gpios: a GPIO spec for the reset pin
> +
> +Example:
> +
> +   mdss_dsi@fd922800 {
> +   panel@0 {
> +   compatible = "sharp,ls043t1le01-qhd";
> +   reg = <0>;
> +   avdd-supply = <_l22>;
> +   backlight = <_wled>;
> +   reset-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
> +   };
> +   };
> --
> 2.4.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Vinod Koul]

On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote:
> Vinod,
> 
> On 11/02/2015 12:04 PM, Vinod Koul wrote:
> > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote:
> >> Hi,
> >>
> >> 1) This seems to have broken BBB in -next for me, bisected down to this 
> >> patch.
> >>
> >> For bootlog:
> >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
> >>
> >> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> >> at least without an ack from the platform maintainer. It can be a a
> >> huge mess if they end up causing conflicts, so we always ask to merge
> >> the DT changes through the platform maintainer (Tony in this case) by
> >> default.
> > 
> > I did warn when applying that I am doing so without ACK on ARM code, noone
> > said a thing!
> > 
> > I knew Tony was following the work by Peter so assumed he must have been 
> > okay
> > with it otherwise would have spoken for ~couple of weeks these were in
> > review
> > 
> > Anyway now that we have a regression, I can revert this patch if that fixes,
> > please confirm, but might break edma... peter?
> 
> Can you revert or drop the last two DTS patches?
> 
> I think I will try a different route to get the split of the tpcc and tptc.
> Without the DT patches the driver will fall back to the legacy mode so things
> will work in a same way they did before.
> Or I can send a followup patch for edma.c, with that there is no need to add
> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better.
> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod
> code will not shut it down but we will keep the possibility to manage the
> power state still.

Okay I have reverted the two and applied the edma patch sent, can you please
verify topic/edma_fix before I merge it and send my PULL request.

Would appreciate any tested-by

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

[Peter Ujfalusi]

The eDMA3 TPTC does not need any software configuration, but it is a
separate IP block in the SoC. In order the omap hwmod core to be able to
handle the TPTC resources correctly in regards of PM we need to have a
driver loaded for it.
This patch will add a dummy driver skeleton without probe or remove
callbacks provided.

Signed-off-by: Peter Ujfalusi 
Reported-by: Olof Johansson 
---
Hi,

while it would have been possible to add the edma3-tptc compatible to be handled
by the edma-tpcc driver (and when the device is tptc, do nothing) it would
make the driver code a bit harder to follow.
I think having separate structure for the tptc looks better and if we ever need
to have separate driver for the tptc it will be cleaner for us the separate it.

This patch alone w/o any hwmod flag changes will make sure that the edma-tptc is
not powered down after the kernel is finished it's booting.

Regards,
Peter

 drivers/dma/edma.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 31722d436a42..6b03e4e84e6b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
{}
 };
 
+static const struct of_device_id edma_tptc_of_ids[] = {
+   { .compatible = "ti,edma3-tptc", },
+   {}
+};
+
 static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
 {
return (unsigned int)__raw_readl(ecc->base + offset);
@@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
},
 };
 
+static struct platform_driver edma_tptc_driver = {
+   .driver = {
+   .name   = "edma3-tptc",
+   .of_match_table = edma_tptc_of_ids,
+   },
+};
+
 bool edma_filter_fn(struct dma_chan *chan, void *param)
 {
bool match = false;
@@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
 
 static int edma_init(void)
 {
+   int ret;
+
+   ret = platform_driver_register(_tptc_driver);
+   if (ret)
+   return ret;
+
return platform_driver_register(_driver);
 }
 subsys_initcall(edma_init);
@@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
 static void __exit edma_exit(void)
 {
platform_driver_unregister(_driver);
+   platform_driver_unregister(_tptc_driver);
 }
 module_exit(edma_exit);
 
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/6] drivers: psci: replace psci firmware calls

[Will Deacon]

On Mon, Nov 02, 2015 at 02:08:26PM +0100, Jens Wiklander wrote:
> On Mon, Nov 02, 2015 at 11:55:39AM +, Will Deacon wrote:
> > On Thu, Oct 29, 2015 at 09:21:24AM +0100, Jens Wiklander wrote:
> > > Switch to use a generic interface for issuing SMC/HVC based on ARM SMC
> > > Calling Convention. Removes now the now unused psci-call.S.
> > > 
> > > Signed-off-by: Jens Wiklander 
> > > ---
> > >  arch/arm/kernel/Makefile  |  1 -
> > >  arch/arm/kernel/psci-call.S   | 31 ---
> > >  arch/arm64/kernel/Makefile|  2 +-
> > >  arch/arm64/kernel/psci-call.S | 28 
> > >  drivers/firmware/psci.c   | 21 +++--
> > >  5 files changed, 20 insertions(+), 63 deletions(-)
> > >  delete mode 100644 arch/arm/kernel/psci-call.S
> > >  delete mode 100644 arch/arm64/kernel/psci-call.S
> > 
> > [...]
> > 
> > > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> > > index 42700f0..53c9606 100644
> > > --- a/drivers/firmware/psci.c
> > > +++ b/drivers/firmware/psci.c
> > > @@ -19,6 +19,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  
> > >  #include 
> > > @@ -56,8 +57,6 @@ struct psci_operations psci_ops;
> > >  
> > >  typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > >   unsigned long, unsigned long);
> > > -asmlinkage psci_fn __invoke_psci_fn_hvc;
> > > -asmlinkage psci_fn __invoke_psci_fn_smc;
> > >  static psci_fn *invoke_psci_fn;
> > >  
> > >  enum psci_function {
> > > @@ -70,6 +69,24 @@ enum psci_function {
> > >  
> > >  static u32 psci_function_id[PSCI_FN_MAX];
> > >  
> > > +static unsigned long __invoke_psci_fn_hvc(unsigned long a0, unsigned 
> > > long a1,
> > > + unsigned long a2, unsigned long a3)
> > 
> > Minor comment, but could we keep these argument names the same as before
> > please?
> 
> You mean function_id, arg0, arg1... instead? I guess I should update
> arm-smccc.h also then.

No; I think just updating the psci caller to use those, but leave the
SMCCC low-level details as they are. The latter is just pushing data,
whilst the former has some (albeit limited) knowledge of what those
values represent.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 14/16] hwmon: add TI LMU hardware fault monitoring driver

[Guenter Roeck]

On 11/01/2015 09:24 PM, Milo Kim wrote:

LM3633 and LM3697 are TI LMU MFD device.
Those device have hardware monitoring feature which detects opened or
shorted circuit case.


Sure, but it only makes sense if you provide standard hwmon attributes
which can be interpreted by the "sensors" command. Which is not the case
here. You neither have a standard device type (light is not handled by hwmon),
nor standard attributes, nor do the attributes return standard values.

I think there may be a basic misunderstanding. hwmon is not intended
to monitor a specific chip on the board. Its scope is to monitor the
system (such as temperature, voltages, or current).

In your case, it might be better to attach the attributes to the mfd device.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/13] drm/panel: simple: Add simple panel device tree binding

[Rob Herring]

On Sat, Oct 31, 2015 at 7:56 AM, Chris Zhong  wrote:

Your subject should be more specific with the panel name.

> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
> Bindings for three specific panels are provided to show how the
> simple panel binding can be used.
>
> Signed-off-by: Chris Zhong 
>
> ---
>
> Changes in v2:
> As Thierry.Reding comment, add a documentation for this panel.
>
>  Documentation/devicetree/bindings/panel/boe,tv080wum-nl0.txt | 7 +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/boe,tv080wum-nl0.txt

Please move to bindings/display/panel/

>
> diff --git a/Documentation/devicetree/bindings/panel/boe,tv080wum-nl0.txt 
> b/Documentation/devicetree/bindings/panel/boe,tv080wum-nl0.txt
> new file mode 100644
> index 000..50be5e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/boe,tv080wum-nl0.txt
> @@ -0,0 +1,7 @@
> +Boe Corporation 8.0" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "boe,tv080wum-nl0"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Andrew F. Davis]

On 11/02/2015 03:17 AM, Lee Jones wrote:

On Fri, 30 Oct 2015, Andrew F. Davis wrote:


On 10/30/2015 02:06 PM, Lee Jones wrote:

On Fri, 30 Oct 2015, Andrew F. Davis wrote:


On 10/30/2015 12:10 PM, Lee Jones wrote:

On Thu, 29 Oct 2015, Andrew F. Davis wrote:


The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.

Signed-off-by: Andrew F. Davis 
---
  .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +++


Why have you dropped Linus' Review-by?



Strange, I thought I made a change to this. Well this brings up a question,
how much change can we have before we are supposed to drop Reviewed/Acked-by?


Common sense call I'm afraid. ;)

[...]


+ the second cell is used to specify flags.
+ See include/dt-bindings/gpio/gpio.h for possible values.


This is a Linuxisum and shouldn't really live in here.

I think it would be better to document them in ../gpio/gpio.txt and
reference that instead.



Looks like that is already in ../gpio/gpio.txt:57


There is a mention of GPIO_ACTIVE_HIGH, as it's used in an example.
However GPIO_ACTIVE_LOW is missing.  I think both could do with
documenting properly, then you can refer to them from here.



I mean the lines above the example, they say to use the macros
defined in include/dt-bindings/gpio/gpio.h whenever possible,
that's really all I would say.


Let's at least attempt to stick to the rules.

Please adapt your formatting to  in order to
eradicate any Linuxiness.



Works for me, although I pushed v6 a couple days ago with a different
fix, maybe that will work too?


[...]


+Required properties:
+ - compatible : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent : The parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller : Marks the device node as an interrupt controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ ../interrupt-controller/interrupts.txt


Nit: We *normally* treat these as bullet-points and not place
full-stops on them:

$ git grep "compatible" -- Documentation/devicetree/bindings/ | grep -v "\.$" | 
wc -l
5227
$ git grep "compatible.*\.$" -- Documentation/devicetree/bindings/ | wc -l
486



What about for multi-sentence descriptions, we need the middle full-stops, then 
to not
have one on the end seems kinda odd looking.


That's the way I usually do it -- doesn't look too bad. ;)

[...]




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

[Krzysztof Kozlowski]

2015-11-02 22:01 GMT+09:00 Alim Akhtar :
>>>
>>>   arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349
>>> +++
>>>   1 file changed, 349 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> index 838a3626dac1..8ce04a0ec928 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> @@ -53,6 +53,355 @@
>>>  status = "okay";
>>>   };
>>>
>>> +_4 {
>>> +   samsung,i2c-sda-delay = <100>;
>>> +   samsung,i2c-max-bus-freq = <20>;
>>> +   status = "okay";
>>> +
>>> +   s2mps15_pmic@66 {
>>> +   compatible = "samsung,s2mps15-pmic";
>>> +   reg = <0x66>;
>>> +   interrupts = <2 0>;
>>> +   interrupt-parent = <>;
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_irq>;
>>> +   wakeup-source;
>>> +
>>> +   s2mps15_osc: clocks {
>>> +   compatible = "samsung,s2mps13-clk";
>>> +   #clock-cells = <1>;
>>> +   clock-output-names = "s2mps13_ap", "s2mps13_cp",
>>> +   "s2mps13_bt";
>>> +   };
>>
>>
>> Don't you want to use one of these clocks for s3c-rtc ( node)?
>>
> yes, you are right, rtc on this board is currently broken, mainly because of
> the introduction of rtc_src clock in the s3c-rtc driver.
> That is on my do list next. will take a look.
>
> Are you suggesting to remove this -clk node now and add along with rtc
> changes? I feel this should go in along with this patch.

Just add it in consecutive patch in this series. You added here some
providers (clock and regulators) without consumers. This of course
looks good as a way of providing full description of the board but:
1. For regulators always on: may be meaningless for kernel. Kernel
does not use it. Existence of regulator subnode will fulfill driver's
needs for probe.
2. For clocks: actually will disable these clocks because of lack of
consumers... which is fine but probably not what you wanted.

The standard approach is to add such providers when they are needed -
there are some consumers using them.

>>> +
>>> +   regulators {
>>> +   ldo1_reg: LDO1 {
>>> +   regulator-name = "vdd_ldo1";
>>> +   regulator-min-microvolt = <50>;
>>> +   regulator-max-microvolt = <90>;
>>> +   regulator-always-on;
>>> +   regulator-enable-ramp-delay = <125>;
>>> +   };

(...)

>>> +
>>> +   buck10_reg: BUCK10 {
>>> +   regulator-name = "vdd_buck10";
>>> +   regulator-min-microvolt = <100>;
>>> +   regulator-max-microvolt = <300>;
>>> +   regulator-boot-on;
>>> +   regulator-always-on;
>>> +   regulator-ramp-delay = <25000>;
>>> +   regulator-enable-ramp-delay = <250>;
>>> +   };
>>
>>
>> All of these ldo3 and bucks in vendor tree for Espresso board have
>> ramp delay of 12000. Also they don't have enable-ramp-delay set and
>> voltages sometimes differ. I don't have S2MPS15 datasheet so I don't
>> know what is the true value... I'll leave it up to you but it looks
>> suspicious.
>>
> These values generally comes from our board design team, so I cann't really
> comment on that, it may vary from board revision etc.
> I will check if we have any updated version of recommended value and update
> accordingly.

Okay, just pointing the difference. I cannot verify them.

>
>>> +   };
>>> +   };
>>> +};
>>
>>
>> What will be the benefit of defining all of these regulators if they
>> are always on and without consumers? No one will disable them, no one
>> will change the voltage. Please provide some consumers.
>>
> As many drivers are not yet enabled in arm64 defconfig, that is one of the
> reason why we are not seeing many consumer for these nodes.

That is not a problem. Please send a patch changing the defconfig.
Usually defconfig (for armv7 this would be exynos and multi_v7) should
provide bootable and working environment for all of our supported
boards.

> This is the ground work being done for enabling those. If you insist will
> try to reduce what is being used now. Moreover this was used to verify
> functionality of pmic driver as well.

Actually as a verification I think even adding simple node
"regulators" is sufficient - driver will add all regulators anyway.
However seeing all regulators described for particular board is
good... but lack of consumers is disturbing because this may mean that
it was 

Re: [PATCH 01/14] serial: sh-sci: Drop the interface clock

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Sep 14, 2015 at 2:14 PM, Laurent Pinchart
 wrote:
> As no platform defines an interface clock the SCI driver always fall
> back to a clock named "peripheral_clk". On SH platform that clock is the
> base clock for the SCI functional clock and has the same frequency. On
> ARM platforms that clock doesn't exist, and clk_get() will return the
> default clock for the device. We can thus make the functional clock
> mandatory and drop the interface clock.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Laurent Pinchart 
> ---
>  .../bindings/serial/renesas,sci-serial.txt |  4 +-
>  drivers/tty/serial/sh-sci.c| 60 
> +-
>  2 files changed, 39 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt 
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> index e84b13a8eda3..c390860bc23f 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt

> @@ -2181,6 +2177,38 @@ static struct uart_ops sci_uart_ops = {
>  #endif
>  };
>
> +static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
> +{
> +   /* Get the SCI functional clock. It's called "fck" on ARM. */
> +   sci_port->fclk = clk_get(dev, "fck");
> +   if (!IS_ERR(sci_port->fclk))
> +   return 0;
> +
> +   /*
> +* But it used to be called "sci_ick", and we need to maintain DT
> +* backward compatibility.
> +*/
> +   sci_port->fclk = clk_get(dev, "sci_ick");
> +   if (!IS_ERR(sci_port->fclk))
> +   return 0;
> +
> +   /* SH has historically named the clock "sci_fck". */
> +   sci_port->fclk = clk_get(dev, "sci_fck");
> +   if (!IS_ERR(sci_port->fclk))
> +   return 0;
> +
> +   /*
> +* Not all SH platforms declare a clock lookup entry for SCI devices, 
> in
> +* which case we need to get the global "peripheral_clk" clock.
> +*/
> +   sci_port->fclk = clk_get(dev, "peripheral_clk");
> +   if (!IS_ERR(sci_port->fclk))
> +   return 0;
> +
> +   dev_err(dev, "failed to get functional clock\n");
> +   return PTR_ERR(sci_port->fclk);

This doesn't handle probe deferral correctly.
-EPROBE_DEFER from an earlier clock will be overwritten by -ENOENT from a
later clock, and the driver will never be reprobed.

> +}

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/13] irqchips: fix ARM11MPCore GIC bindings

[Rob Herring]

On Thu, Oct 15, 2015 at 8:46 AM, Linus Walleij  wrote:
> The GIC bindings for the ARM11MPCore need to differentiate between
> the GIC on the Test Chip and the one on the evaluation baseboard.
> Split the binding in two and define new compatible-strings.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/gic.txt | 3 ++-
>  drivers/irqchip/irq-gic.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
> b/Documentation/devicetree/bindings/arm/gic.txt
> index 2da059a4790c..a5445622c216 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -15,7 +15,8 @@ Main node required properties:
> "arm,cortex-a15-gic"
> "arm,cortex-a9-gic"
> "arm,cortex-a7-gic"
> -   "arm,arm11mp-gic"
> +   "arm,tc11mp-gic"
> +   "arm,pb11mp-gic"
> "brcm,brahma-b15-gic"
> "arm,arm1176jzf-devchip-gic"
> "qcom,msm-8660-qgic"
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 982c09c2d791..5376d1cb0a4f 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -1184,7 +1184,8 @@ gic_of_init(struct device_node *node, struct 
> device_node *parent)
> return 0;
>  }
>  IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
> -IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init);
> +IRQCHIP_DECLARE(armtc11mp_gic, "arm,tc11mp-gic", gic_of_init);
> +IRQCHIP_DECLARE(armpb11mp_gic, "arm,pb11mp-gic", gic_of_init);
>  IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", 
> gic_of_init);
>  IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
>  IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Rob Herring]

On Sun, Nov 1, 2015 at 11:01 PM, Milo Kim  wrote:
> LM3633 LED device is one of TI LMU device list.
>
> Cc: devicetree@vger.kernel.org
> Cc: Jacek Anaszewski 
> Cc: Lee Jones 
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-l...@vger.kernel.org
> Signed-off-by: Milo Kim 
> ---
>  .../devicetree/bindings/leds/leds-lm3633.txt   | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt 
> b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
> new file mode 100644
> index 000..bb7f213
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
> @@ -0,0 +1,28 @@
> +TI LMU LM3633 LED device tree bindings
> +
> +Required properties:
> +  - compatible: "ti,lm3633-leds"
> +
> +Child nodes:
> +  Each node matches with LED control bank.
> +  Please refer to the datasheet [1].
> +
> +  Required properties of a child node:
> +  - lvled1-used, lvled2-used, lvled3-used,
> +lvled4-used, lvled5-used, lvled6-used:
> +Low voltage LED string configuration. Type is .
> +Please describe which output LED string is used.

What is "LED string"?

We have properties for which LED driver/channel of the parent to use
and "status" can be used to disable child nodes.

> +
> +  Optional properties of a child node:
> +  - channel-name: Name string for LED channel identification
> +  It is used for creating LED sysfs,
> +  /sys/class/leds//.
> +  If this property is empty, then default name is set to
> +  "indicator:" by the driver.

I believe "label" already provides this function.

> +  - led-max-microamp: Max current setting. Type is .
> +  Unit is microampere. Range is from 5000 to 3.
> +
> +Examples: Please refer to ti-lmu dt-bindings [2].
> +
> +[1] http://www.ti.com/product/LM3633/datasheet
> +[2] Documentation/devicetree/bindings/mfd/ti-lmu.txt
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Rob Herring]

On Fri, Oct 30, 2015 at 7:41 PM, Michael Welling  wrote:
> Adds documentation for the devicetree bindings of the new tsc2004 driver.
>
> Signed-off-by: Michael Welling 
> ---
>  .../bindings/input/touchscreen/tsc2005.txt | 39 
> ++
>  1 file changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> index 09089a6..27c6082 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> @@ -1,3 +1,42 @@
> +* Texas Instruments tsc2004 touchscreen controller
> +
> +Required properties:
> + - compatible: "ti,tsc2004"
> + - interrupts: IRQ specifier
> + - vio-supply : Regulator specifier

reg property?

> +
> +Optional properties:
> + - reset-gpios   : GPIO specifier
> + - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
> plates
> +   in ohm (defaults to 280)
> + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
> after
> +   the configured time (in milli seconds), the 
> driver
> +   will reset it. This is disabled by default.
> + - properties defined in touchscreen.txt
> +
> +Example:
> +
> + {
> +   tsc2004@48 {
> +   compatible = "ti,tsc2004";
> +   reg = <0x48>;
> +   vio-supply = <>;
> +
> +   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
> +   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
> +
> +   touchscreen-fuzz-x = <4>;
> +   touchscreen-fuzz-y = <7>;
> +   touchscreen-fuzz-pressure = <2>;
> +   touchscreen-size-x = <4096>;
> +   touchscreen-size-y = <4096>;
> +   touchscreen-max-pressure = <2048>;
> +
> +   ti,x-plate-ohms = <280>;
> +   ti,esd-recovery-timeout-ms = <8000>;
> +   };
> +}
> +
>  * Texas Instruments tsc2005 touchscreen controller
>
>  Required properties:
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Viresh Kumar]

On 30-10-15, 14:49, Stephen Boyd wrote:
> I suppose if you wanted to have 64 possible combinations of some
> attribute you would just extend it to two 32 bit numbers in
> sequence? I don't see the limitation here, and hopefully there
> isn't a limitation so that we can specify sufficiently large
> numbers with more bits if we need to.

I hope you want to mark this patch with your reviewed-by tag?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Doug Anderson]

Rob,

On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring  wrote:
> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson  
> wrote:
>> From: Doug Anderson 
>>
>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>> port) the PHY can get into a bad state when a wakeup is asserted (not
>> just a wakeup from full system suspend but also a wakeup from
>> autosuspend).
>
> I would think re-enumerating means autosuspend is broken.

Yes, it is broken on this port.  I've been trying to figure out how to
disable autosuspend at the driver level.  Until then we can do it with
udev rules but that's much less ideal.

On our current system we have autosuispend turned off for most things
via udev and laptop-mode-tools.  ...so really the only case we see
this reset happen is if an empty hub is plugged in and then you plug
something into the hub.  The reset isn't terrible and is much better
than the device getting stuck.

You can also see the reset doing its thing if you fully suspend the
system and try to wake up from a keyboard or a mouse attached to the
port.  Being able to wake up (and then seeing a reset) is still better
than not being able to wake up.


>> We can get the PHY out of its bad state by asserting its "port reset",
>> but unfortunately that seems to assert a reset onto the USB bus so it
>> could confuse things if we don't actually deenumerate / reenumerate the
>> device.
>>
>> We can also get the PHY out of its bad state by fully resetting it using
>> the reset from the CRU (clock reset unit), which does a more full
>> reset.  The CRU-based reset appears to actually cause devices on the bus
>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>> way).
>
> The reset from the CRU goes to the PHY, correct? Therefore, the
> binding should reflect that. Connecting it to the host controller is a
> hack.
>
> So describe the reset connection properly and then add a .phy_reset()
> hook to the phy subsystem. Then call that when flag property you added
> is set.

As per previous email, I disagree.  The fact that there may be more
than one reset exposed from the PHY and that there is not a tightly
coupled relationship between a PHY driver and a USB driver means that
we would need to re-invent the reset API on top of the PHY API.  In my
case I am exposing a single reset at the moment, but there may be
reasons to expose additional "PHY" resets in the future.

http://www.gossamer-threads.com/lists/linux/kernel/2289780#2289780

...using the existing reset API seems better.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux-next 0/4] mtd: spi-nor: fix Quad SPI memory support

[Cyrille Pitchen]

Le 02/11/2015 02:07, Marek Vasut a écrit :
> On Friday, September 18, 2015 at 05:49:24 PM, Cyrille Pitchen wrote:
>> Hi all,
> 
> Hi!
> 
Hi Marek!

>> this series of patches fixes the QSPI support mostly for Micron and
>> Macronix memories. There are also some updates for Spansion memories.
>> There are also many comments to explain the implementation choices based
>> on the datasheets from memory manufacturers.
>>
>> The series was backported to a at91-4.1 kernel then tested on a sama5d2
>> xplained board, which embeds a at25df321a memory on a SPI controller and
>> a Micron n25q128a13 QSPI memory on the new Atmel QSPI controller.
>>
>> The at25 memory was used to check non regression on the m25p80 driver
>> whereas the Micron memory was used to test the fixes of the spi-nor
>> framework. The driver for the Atmel QSPI controller will be sent in a
>> dedicated series.
> 
> Are there any news on this patch series? I'd like to use that for my own
> QSPI driver (the Cadence one), so I'd like to check on the status. Are you
> still working on this please ?
> 
Nothing new from my side. This series of patches should have taken into account
all the comments I'd received from previous series. At least, I hope so.
If I forgot some points or if something is still missing, let me know and I'll
update the series accordingly.

I also wait for a kind of agreement on how we could update the framework API
so that more QSPI memories could be supported. I have already written a driver
for an Atmel QSPI controller. This driver is based on this series of patches.
I have to know what the updated API will be before sending another series for
the QSPI controller driver. So this series is one proposal for some API updates
but other proposals may exist.

I've asked Brian on IRC for review and pieces of advice on how he thinks the
work should be done. I've understood he's right now a little bit busy. I'm fine
with it. I also often have to deal with many topics almost in the same time so
I can understand whether he needs more time.

Anyway, I guess Brian has already started to review these patches since last
Friday he referred to a previous talk we had about some leading space:

http://lists.infradead.org/pipermail/linux-mtd/2015-October/062956.html


> Thanks!
> 
> Best regards,
> Marek Vasut
> 

Best regards,

Cyrille
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

[Alim Akhtar]

On 11/02/2015 05:55 PM, Krzysztof Kozlowski wrote:

2015-11-02 19:04 GMT+09:00 Alim Akhtar :

This patch add pmic (s2mps15) node of espresso board,


This patch adds PMIC (S2MPS15)...


which includes addition of regulators and pmic-clk sub-nodes.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Alim Akhtar 
---
This patch should go in after driver side changes [1] lands.
[1]-> 
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg47736.html


Eh? Why? Usually there is not such requirement.

Got it, I just thought without driver changes these dts modification 
does not make sense. Thanks for clarification.


  arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349 +++
  1 file changed, 349 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 838a3626dac1..8ce04a0ec928 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -53,6 +53,355 @@
 status = "okay";
  };

+_4 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <20>;
+   status = "okay";
+
+   s2mps15_pmic@66 {
+   compatible = "samsung,s2mps15-pmic";
+   reg = <0x66>;
+   interrupts = <2 0>;
+   interrupt-parent = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq>;
+   wakeup-source;
+
+   s2mps15_osc: clocks {
+   compatible = "samsung,s2mps13-clk";
+   #clock-cells = <1>;
+   clock-output-names = "s2mps13_ap", "s2mps13_cp",
+   "s2mps13_bt";
+   };


Don't you want to use one of these clocks for s3c-rtc ( node)?

yes, you are right, rtc on this board is currently broken, mainly 
because of the introduction of rtc_src clock in the s3c-rtc driver.

That is on my do list next. will take a look.

Are you suggesting to remove this -clk node now and add along with rtc 
changes? I feel this should go in along with this patch.



+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "vdd_ldo1";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <90>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo2_reg: LDO2 {
+   regulator-name = "vdd_ldo2";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <125>;
+   regulator-always-on;
+   };
+
+   ldo3_reg: LDO3 {
+   regulator-name = "vdd_ldo3";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo4_reg: LDO4 {
+   regulator-name = "vdd_ldo4";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <111>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo5_reg: LDO5 {
+   regulator-name = "vdd_ldo5";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo6_reg: LDO6 {
+   regulator-name = "vdd_ldo6";
+   regulator-min-microvolt = <225>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo7_reg: LDO7 {
+   regulator-name = "vdd_ldo7";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <115>;
+   regulator-always-on;
+ 

Re: [PATCH v6 2/6] drivers: psci: replace psci firmware calls

[Jens Wiklander]

On Mon, Nov 02, 2015 at 11:55:39AM +, Will Deacon wrote:
> On Thu, Oct 29, 2015 at 09:21:24AM +0100, Jens Wiklander wrote:
> > Switch to use a generic interface for issuing SMC/HVC based on ARM SMC
> > Calling Convention. Removes now the now unused psci-call.S.
> > 
> > Signed-off-by: Jens Wiklander 
> > ---
> >  arch/arm/kernel/Makefile  |  1 -
> >  arch/arm/kernel/psci-call.S   | 31 ---
> >  arch/arm64/kernel/Makefile|  2 +-
> >  arch/arm64/kernel/psci-call.S | 28 
> >  drivers/firmware/psci.c   | 21 +++--
> >  5 files changed, 20 insertions(+), 63 deletions(-)
> >  delete mode 100644 arch/arm/kernel/psci-call.S
> >  delete mode 100644 arch/arm64/kernel/psci-call.S
> 
> [...]
> 
> > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> > index 42700f0..53c9606 100644
> > --- a/drivers/firmware/psci.c
> > +++ b/drivers/firmware/psci.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -56,8 +57,6 @@ struct psci_operations psci_ops;
> >  
> >  typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > unsigned long, unsigned long);
> > -asmlinkage psci_fn __invoke_psci_fn_hvc;
> > -asmlinkage psci_fn __invoke_psci_fn_smc;
> >  static psci_fn *invoke_psci_fn;
> >  
> >  enum psci_function {
> > @@ -70,6 +69,24 @@ enum psci_function {
> >  
> >  static u32 psci_function_id[PSCI_FN_MAX];
> >  
> > +static unsigned long __invoke_psci_fn_hvc(unsigned long a0, unsigned long 
> > a1,
> > +   unsigned long a2, unsigned long a3)
> 
> Minor comment, but could we keep these argument names the same as before
> please?

You mean function_id, arg0, arg1... instead? I guess I should update
arm-smccc.h also then.

> 
> > +{
> > +   struct smccc_res res;
> > +
> > +   smccc_hvc(a0, a1, a2, a3, 0, 0, 0, 0, );
> 
> It's slightly tempting to use varargs instead of the '0' argument padding,
> but that will probably make the asm code unmanageable.

Agree.

Thanks,
Jens
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Doug Anderson]

Hi,

On Mon, Nov 2, 2015 at 9:16 AM, Rob Herring  wrote:
> On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson  wrote:
>> Rob,
>>
>> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring  wrote:
>>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson  
>>> wrote:
 From: Doug Anderson 
>
 We can get the PHY out of its bad state by asserting its "port reset",
 but unfortunately that seems to assert a reset onto the USB bus so it
 could confuse things if we don't actually deenumerate / reenumerate the
 device.

 We can also get the PHY out of its bad state by fully resetting it using
 the reset from the CRU (clock reset unit), which does a more full
 reset.  The CRU-based reset appears to actually cause devices on the bus
 to be removed and reinserted, which fixes the problem (albeit in a hacky
 way).
>>>
>>> The reset from the CRU goes to the PHY, correct? Therefore, the
>>> binding should reflect that. Connecting it to the host controller is a
>>> hack.
>>>
>>> So describe the reset connection properly and then add a .phy_reset()
>>> hook to the phy subsystem. Then call that when flag property you added
>>> is set.
>>
>> As per previous email, I disagree.  The fact that there may be more
>> than one reset exposed from the PHY and that there is not a tightly
>> coupled relationship between a PHY driver and a USB driver means that
>> we would need to re-invent the reset API on top of the PHY API.  In my
>> case I am exposing a single reset at the moment, but there may be
>> reasons to expose additional "PHY" resets in the future.
>
> Your previous approach was completely different. I was not arguing
> that the PHY driving reset to the host was wrong use of reset binding,
> just that it was an overkill. Now, it is just flat wrong unless you
> convince me that SRST_USBHOST1_PHY is a connection to the host rather
> than the PHY.

It still seems to me that the argument that there can be multiple
types of "phy reset" is still a sane argument.  Just because we
currently happen to need the one that resets the whole PHY now doesn't
mean that we won't need other different resets later.

...and if you're exposing multiple different resets, then the reset
API is the best one to use.

I _could_ see the argument that perhaps the reset should pass through
the PHY driver so that it could possibly in the future be aware of the
reset.  That is: the SRST could use the reset API to expose the PHY
reset to the PHY driver and then the PHY driver could in turn expose
the PHY reset (using the reset API) to the dwc2 driver.  At the moment
this would be a complete pass through, but structuring it that way
would later allow the PHY to do something with the reset.  How about
that?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 0/3] ARM: dts: NSP: Add PCI, NAND, and TWD Support to DT

[Jon Mason]

Resending due to lack of any response to the original series

Add PCI, NAND, and TWD Support to the Broadcom Northstar Plus SoC device
tree file.  Since no driver changes are needed to enable these pieces of
hardware, only the device tree changes are required to make them
functional.

Jon Mason (3):
  ARM: dts: NSP: Add PCI support
  ARM: dts: NSP: Add NAND Support to DT
  ARM: dts: NSP: Add TWD Support to DT

 arch/arm/boot/dts/bcm-nsp.dtsi   | 104 ++-
 arch/arm/boot/dts/bcm958625k.dts |  50 +++
 2 files changed, 153 insertions(+), 1 deletion(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 0/3] ARM: dts: NSP: Add PCI, NAND, and TWD Support to DT

[Florian Fainelli]

On 02/11/15 10:40, Jon Mason wrote:
> Resending due to lack of any response to the original series
> 
> Add PCI, NAND, and TWD Support to the Broadcom Northstar Plus SoC device
> tree file.  Since no driver changes are needed to enable these pieces of
> hardware, only the device tree changes are required to make them
> functional.

Series applied to devicetree/next, thanks Jon!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND v4 0/2] ARM: dts: bcm5301x: Add SVK DT files and docs

[Florian Fainelli]

On 02/11/15 10:34, Jon Mason wrote:
> Resending due to lack of any response to the original v4 series
> 
> Changes in v4:
> * Changed bootargs to stdout-path, per Sudeep Holla
> 
> Changes in v3:
> * Updated the DT documentation compat strings
> * Modified the include files and compat strings for the SVK DT files,
>   per Hauke Mehrtens
> 
> Changes in v2:
> * Reorder the patches to add the DT binding documentation prior to the
>   new DT files
> * Removed the DT documentation compat strings to only the SoCs, not the
>   individual boards
> * Fixed the compat strings in the individual device tree files
> * Added the memory node and removed the "mem=" from the bootargs

Series applied to devicetree/next, thanks Jon!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] iio: Heart Rate Monitors

[Andrew F. Davis]

On 11/01/2015 12:35 PM, Jonathan Cameron wrote:

On 31/10/15 16:31, Andrew F. Davis wrote:

Hello all,

This series adds the TI AFE4404 "Ultra-small, Integrated AFE for
Wearable, Optical Heart Rate Monitoring and Bio-Sensing".

This work is based on previous work by Dan Murphy [0] who is working
on other tasks at the moment, so I will be helping to continue
upstreaming this driver. This is more of a re-write than a continuation
and there are many changes so I am submitting this as a v1.

This device is very similar to the AFE4403 and I was originally planning
on pushing the two drivers together with common core functions in a
third file. The AFE4403 driver is still being tested so I merged common
code back into this driver, this is why this driver may seem a bit
unnecessarily modular. I will probably split this stuff back out when
I push the AFE4403.

I also had some issues with sysfs naming for the channels; this device
has three input channels from three LED stages and two ambient
channels based on the LED stages. This might have been be a good place
for using IIO modifiers[1], but we also have two differential channels
based on the ambient channels, and channels cannot have both modifiers
and be differential (the modifier is stored in the differential channel's
ID field?).

True enough. Didn't expect to run into this particular problem, but I guess
someone will always make hardware breaking any assumptions we make from the
software side of things.


Seems that way, it probably would work to have modified be more that a single
bit flag, maybe call it modifier and just store the modifier in there. Doesn't
look like it would be that hard right now to fix.

I'm not really sure I understand the need for modifiers at all really, seems
most are used by a single driver to get around just naming the channel.


So I used sysfs names that would be close to what they
would be if IIO supported these things.

Fair enough as a starting point though we probably want to figure out how
to do this 'right'.   Adding an extra field to the channel descriptor will
be easy enough - it'll be event codes that are nasty to handle.

Jonathan


[0] http://www.spinics.net/lists/linux-iio/msg18413.html
[1] IIO_MOD_TEMP_AMBIENT could be renamed IIO_MOD_AMBIENT as it can
also apply to LIGHT, PRESSURE, HUMIDITY, etc..

No problem with this change so please send a patch.


Thanks,
Andrew

Andrew F. Davis (2):
   Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor
   iio: health: Add driver for the TI AFE4404 heart monitor

  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  70 +++
  .../devicetree/bindings/iio/health/afe4404.txt |  27 ++
  drivers/iio/Kconfig|   1 +
  drivers/iio/Makefile   |   1 +
  drivers/iio/health/Kconfig |  24 +
  drivers/iio/health/Makefile|   6 +
  drivers/iio/health/afe4404.c   | 526 +
  drivers/iio/health/afe440x.h   | 159 +++
  8 files changed, 814 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4404.txt
  create mode 100644 drivers/iio/health/Kconfig
  create mode 100644 drivers/iio/health/Makefile
  create mode 100644 drivers/iio/health/afe4404.c
  create mode 100644 drivers/iio/health/afe440x.h




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Rob Herring]

On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson  wrote:
> Rob,
>
> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring  wrote:
>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson  
>> wrote:
>>> From: Doug Anderson 

>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit), which does a more full
>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>
>> The reset from the CRU goes to the PHY, correct? Therefore, the
>> binding should reflect that. Connecting it to the host controller is a
>> hack.
>>
>> So describe the reset connection properly and then add a .phy_reset()
>> hook to the phy subsystem. Then call that when flag property you added
>> is set.
>
> As per previous email, I disagree.  The fact that there may be more
> than one reset exposed from the PHY and that there is not a tightly
> coupled relationship between a PHY driver and a USB driver means that
> we would need to re-invent the reset API on top of the PHY API.  In my
> case I am exposing a single reset at the moment, but there may be
> reasons to expose additional "PHY" resets in the future.

Your previous approach was completely different. I was not arguing
that the PHY driving reset to the host was wrong use of reset binding,
just that it was an overkill. Now, it is just flat wrong unless you
convince me that SRST_USBHOST1_PHY is a connection to the host rather
than the PHY.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Rob Herring]

On Mon, Nov 2, 2015 at 11:26 AM, Timur Tabi  wrote:
> On 11/02/2015 10:20 AM, Sinan Kaya wrote:
>>>
>>>
>> Is there a good example I can look or a wiki about the device-tree
>> naming conventions?

There are many examples. Generally, it is the form of:

,-

>>
>> I'm more of an ACPI person than DTS.
>
>
> I think Rob is talking about something like this:
>
> compatible="qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"
>
> This specifies that this is the v1.0 of the HIDMA management engine (or, the
> management engine for the 1.0 HIDMA device).  That way, if in the future
> there's a v1.1, you can do this:
>
> compatible="qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt"

Except I was suggesting not using 1.0 or 1.1. There is one main
exception and that is Xilinx blocks, but they are releasing versions
of blocks to customers. If "1.0" is not a well defined number, then
don't use that. I'd be surprised if any SOC vendor had such well
defined process around versioning of their IP blocks such that they
are well documented and guaranteed such that every change will change
the version.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Rob Herring]

On Mon, Nov 2, 2015 at 11:48 AM, Timur Tabi  wrote:
> On 11/02/2015 11:42 AM, Rob Herring wrote:
>>
>> On Mon, Nov 2, 2015 at 11:26 AM, Timur Tabi  wrote:
>>>
>>> >On 11/02/2015 10:20 AM, Sinan Kaya wrote:
>
> >>>
> >>>

 >>Is there a good example I can look or a wiki about the device-tree
 >>naming conventions?
>>
>> There are many examples. Generally, it is the form of:
>>
>> ,-
>>
>
> The problem is that we don't actually have an official name for this chip
> yet.

Then document it with "" and fill that in later. Just don't make
up version numbers.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND v4 1/2] dt-bindings: Add new SoCs to bcm4708 DT bindings

[Jon Mason]

Add the 4708, 4709, and 53012 SoCs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 
Acked-by: Hauke Mehrtens 
Acked-by: Scott Branden 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..8608a77 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:
 
 Required root node property:
 
+bcm4708
 compatible = "brcm,bcm4708";
+
+bcm4709
+compatible = "brcm,bcm4709";
+
+bcm53012
+compatible = "brcm,bcm53012";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND v4 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files

[Jon Mason]

Add device tree files for Broadcom Northstar based SVKs.  Since the
bcm5301x.dtsi already exists, all that is necessary is the dts files to
enable the UARTs.  With these files, the SVKs are able to boot to shell.

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/Makefile   |  5 +++-
 arch/arm/boot/dts/bcm94708.dts   | 56 +++
 arch/arm/boot/dts/bcm94709.dts   | 56 +++
 arch/arm/boot/dts/bcm953012k.dts | 63 
 4 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/bcm94708.dts
 create mode 100644 arch/arm/boot/dts/bcm94709.dts
 create mode 100644 arch/arm/boot/dts/bcm953012k.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..96a1b58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm47081-buffalo-wzr-900dhp.dtb \
bcm4709-asus-rt-ac87u.dtb \
bcm4709-buffalo-wxr-1900dhp.dtb \
-   bcm4709-netgear-r8000.dtb
+   bcm4709-netgear-r8000.dtb \
+   bcm94708.dtb \
+   bcm94709.dtb \
+   bcm953012k.dtb
 dtb-$(CONFIG_ARCH_BCM_63XX) += \
bcm963138dvt.dtb
 dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
new file mode 100644
index 000..251a486
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+   model = "NorthStar SVK (BCM94708)";
+   compatible = "brcm,bcm94708", "brcm,bcm4708";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x 0x0800>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
new file mode 100644
index 000..b16cac9
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

[PATCH RESEND v4 0/2] ARM: dts: bcm5301x: Add SVK DT files and docs

[Jon Mason]

Resending due to lack of any response to the original v4 series

Changes in v4:
* Changed bootargs to stdout-path, per Sudeep Holla

Changes in v3:
* Updated the DT documentation compat strings
* Modified the include files and compat strings for the SVK DT files,
  per Hauke Mehrtens

Changes in v2:
* Reorder the patches to add the DT binding documentation prior to the
  new DT files
* Removed the DT documentation compat strings to only the SoCs, not the
  individual boards
* Fixed the compat strings in the individual device tree files
* Added the memory node and removed the "mem=" from the bootargs


Add device tree files and update the documentation for Broadcom
Northstar based SVKs.  Since the bcm5301x.dtsi already exists, all that
is necessary is the dts files to enable the UARTs.  With these files,
the SVKs are able to boot to shell

Jon Mason (2):
  dt-bindings: Add new SoCs to bcm4708 DT bindings
  ARM: dts: bcm5301x: Add BCM SVK DT files

 .../devicetree/bindings/arm/bcm/brcm,bcm4708.txt   |  7 +++
 arch/arm/boot/dts/Makefile |  5 +-
 arch/arm/boot/dts/bcm94708.dts | 56 +++
 arch/arm/boot/dts/bcm94709.dts | 56 +++
 arch/arm/boot/dts/bcm953012k.dts   | 63 ++
 5 files changed, 186 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/bcm94708.dts
 create mode 100644 arch/arm/boot/dts/bcm94709.dts
 create mode 100644 arch/arm/boot/dts/bcm953012k.dts

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Timur Tabi]

On 11/02/2015 12:25 PM, Rob Herring wrote:

Then document it with "" and fill that in later. Just don't make
up version numbers.


I don't think you understand.  We literally have no name for our chip. 
The closest is what I used on the pin control driver, "qdf2xxx", which 
really doesn't say anything.


"qcom,qdf2xxx-hidma-mgmt"

doesn't sound right.

As for version numbers, sorry, I don't know what I was thinking.  I 
wrote plenty of device trees the way you suggest, I just forgot about them.


--
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/2/2015 12:42 PM, Rob Herring wrote:

Except I was suggesting not using 1.0 or 1.1. There is one main
exception and that is Xilinx blocks, but they are releasing versions
of blocks to customers. If "1.0" is not a well defined number, then
don't use that. I'd be surprised if any SOC vendor had such well
defined process around versioning of their IP blocks such that they
are well documented and guaranteed such that every change will change
the version.


Here is one.

I have two versions of the same IP. The first version in one chip has 
sw_version register that returns 1.0. The second version which has more 
capabilities has 1.1 in it.


Is it OK to use?

compatible="qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"

for now and

compatible="qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt"

later for the second chip? 1.1 is backwards compatible with 1.0 BTW.

Since the same IP goes into multiple chips, why would you list the chip 
name here and submit patches multiple times for each single chip.


or to follow what Timur did, I can do this.

"qcom,qdf2xxx-hidma-mgmt-1.0"

qdf2xxx would become the chip family.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Timur Tabi]

On 11/02/2015 11:42 AM, Rob Herring wrote:

On Mon, Nov 2, 2015 at 11:26 AM, Timur Tabi  wrote:

>On 11/02/2015 10:20 AM, Sinan Kaya wrote:

>>>
>>>

>>Is there a good example I can look or a wiki about the device-tree
>>naming conventions?

There are many examples. Generally, it is the form of:

,-



The problem is that we don't actually have an official name for this 
chip yet.



--
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 3/3] ARM: dts: NSP: Add TWD Support to DT

[Jon Mason]

Add support for the ARM TWD Timer and Watchdog to the Northstar Plus
device tree.

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 62bc86f..4bcdd28 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -80,6 +80,22 @@
interrupts = ;
clocks = <_clk>;
};
+
+   twd-timer@19020600 {
+   compatible = "arm,cortex-a9-twd-timer";
+   reg = <0x0600 0x20>;
+   interrupts = ;
+   clocks = <_clk>;
+   };
+
+   twd-watchdog@19020620 {
+   compatible = "arm,cortex-a9-twd-wdt";
+   reg = <0x0620 0x20>;
+   interrupts = ;
+   clocks = <_clk>;
+   };
};
 
clocks {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 1/3] ARM: dts: NSP: Add PCI support

[Jon Mason]

Add PCI support to the Northstar Plus SoC.  This uses the existing
pcie-iproc driver.  So, all that is needed is device tree entries in the
DTS.

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/bcm-nsp.dtsi   | 74 +++-
 arch/arm/boot/dts/bcm958625k.dts | 12 +++
 2 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..85fb1c8 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -96,7 +96,7 @@
 
axi {
compatible = "simple-bus";
-   ranges = <0x 0x1800 0x1000>;
+   ranges = <0x 0x1800 0x00015000>;
#address-cells = <1>;
#size-cells = <1>;
 
@@ -115,5 +115,77 @@
clock-frequency = <62499840>;
status = "disabled";
};
+
+   pcie0: pcie@18012000 {
+   compatible = "brcm,iproc-pcie";
+   reg = <0x12000 0x1000>;
+
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0>;
+   interrupt-map = <0 0 0 0  GIC_SPI 131 
IRQ_TYPE_NONE>;
+
+   linux,pci-domain = <0>;
+
+   bus-range = <0x00 0xff>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+
+   /* Note: The HW does not support I/O resources.  So,
+* only the memory resource range is being specified.
+*/
+   ranges = <0x8200 0 0x0800 0x0800 0 
0x800>;
+
+   status = "disabled";
+   };
+
+   pcie1: pcie@18013000 {
+   compatible = "brcm,iproc-pcie";
+   reg = <0x13000 0x1000>;
+
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0>;
+   interrupt-map = <0 0 0 0  GIC_SPI 137 
IRQ_TYPE_NONE>;
+
+   linux,pci-domain = <1>;
+
+   bus-range = <0x00 0xff>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+
+   /* Note: The HW does not support I/O resources.  So,
+* only the memory resource range is being specified.
+*/
+   ranges = <0x8200 0 0x4000 0x4000 0 
0x800>;
+
+   status = "disabled";
+   };
+
+   pcie2: pcie@18014000 {
+   compatible = "brcm,iproc-pcie";
+   reg = <0x14000 0x1000>;
+
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0>;
+   interrupt-map = <0 0 0 0  GIC_SPI 143 
IRQ_TYPE_NONE>;
+
+   linux,pci-domain = <2>;
+
+   bus-range = <0x00 0xff>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+
+   /* Note: The HW does not support I/O resources.  So,
+* only the memory resource range is being specified.
+*/
+   ranges = <0x8200 0 0x4800 0x4800 0 
0x800>;
+
+   status = "disabled";
+   };
};
 };
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index 16303db..4859268 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -55,3 +55,15 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 2/3] ARM: dts: NSP: Add NAND Support to DT

[Jon Mason]

Add NAND support to the device tree for the Broadcom Northstar Plus SoC.
Since no driver changes are needed to enable this hardware, only the
device tree changes are required to make this functional.

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/bcm-nsp.dtsi   | 16 +++-
 arch/arm/boot/dts/bcm958625k.dts | 38 ++
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 85fb1c8..62bc86f 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -96,7 +96,7 @@
 
axi {
compatible = "simple-bus";
-   ranges = <0x 0x1800 0x00015000>;
+   ranges = <0x 0x1800 0x0011ba08>;
#address-cells = <1>;
#size-cells = <1>;
 
@@ -187,5 +187,19 @@
 
status = "disabled";
};
+
+   nand: nand@18026000 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x026000 0x600>,
+ <0x11b408 0x600>,
+ <0x026f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-has-wp;
+   };
};
 };
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index 4859268..b966955 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -67,3 +67,41 @@
  {
status = "okay";
 };
+
+ {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-on-flash-bbt;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <1024>;
+
+   brcm,nand-oob-sector-size = <27>;
+
+   partition@0 {
+   label = "nboot";
+   reg = <0x 0x0020>;
+   read-only;
+   };
+   partition@1 {
+   label = "nenv";
+   reg = <0x0020 0x0040>;
+   };
+   partition@2 {
+   label = "nsystem";
+   reg = <0x0060 0x00a0>;
+   };
+   partition@3 {
+   label = "nrootfs";
+   reg = <0x0100 0x0300>;
+   };
+   partition@4 {
+   label = "ncustfs";
+   reg = <0x0400 0x3c00>;
+   };
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Kim, Milo]

Hi Lee,

On 11/2/2015 5:59 PM, Lee Jones wrote:

  drivers/video/backlight/Kconfig|  62 ++
>  drivers/video/backlight/Makefile   |   7 +
>  drivers/video/backlight/lm3532_bl.c| 183 +
>  drivers/video/backlight/lm3631_bl.c| 129 
>  drivers/video/backlight/lm3632_bl.c| 125 
>  drivers/video/backlight/lm3633_bl.c| 210 ++
>  drivers/video/backlight/lm3695_bl.c|  91 +++
>  drivers/video/backlight/lm3697_bl.c| 187 +
>  drivers/video/backlight/ti-lmu-backlight.c | 429 
>  drivers/video/backlight/ti-lmu-backlight.h | 152 +

How different are all of these drivers?

Can you create one driver that supports them all instead?



Thanks for your suggestion.

'ti-lmu-backlight' is the common part of lm_bl drivers. And each 
lmxxx_bl has its own operation functions by using ti_lmu_bl_ops.
I've tried to make consolidated driver but it contained too much device 
specific code in one file. So I prefer simple drivers structure - 
'common part' and 'device specific operations'.

It would be appreciated if you could introduce better idea.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 02/16] Documentation: dt-bindings: backlight: add TI LMU backlight binding information

[Kim, Milo]

On 11/3/2015 12:02 AM, Rob Herring wrote:

On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim  wrote:

LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
for describing device.

Cc: devicetree@vger.kernel.org
Cc: Jingoo Han 
Cc: Lee Jones 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  .../bindings/video/backlight/ti-lmu-backlight.txt  | 67 ++


Please move to bindings/leds/backlight/


There are backlight bindings under video/backlight. I'd like to know why 
this 'led' location is preferred. My guess is most of properties are 
from common LED properties. Any other reasons?





  1 file changed, 67 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
new file mode 100644
index 000..27b0036
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
@@ -0,0 +1,67 @@
+TI LMU backlight device tree bindings
+
+Required properties:
+  - compatible: Should be one of lists below.
+"ti,lm3532-backlight"
+"ti,lm3631-backlight"
+"ti,lm3632-backlight"
+"ti,lm3633-backlight"
+"ti,lm3695-backlight"
+"ti,lm3697-backlight"
+
+Optional properties:
+  There are two backlight control mode. One is I2C, the other is PWM mode.
+  Following properties are only specified in PWM mode.
+  Please note that LMU backlight device can have only one PWM channel.
+
+  - pwms: OF device-tree PWM specification.
+  - pwm-names: a list of names for the PWM devices specified in the "pwms"
+   property.
+
+  For the PWM user nodes, please refer to [1].
+
+Child nodes:
+  LMU backlight is represented as sub-nodes of the TI LMU device [2].
+  So, LMU backlight should have more than one backlight child node.
+  Each node exactly matches with backlight control bank configuration.
+  Maximum numbers of child nodes depend on the device.
+  1 = LM3631, LM3632, LM3695
+  2 = LM3633, LM3697
+  3 = LM3532
+
+  Required property of a child node:
+  - hvled1-used, hvled2-used, hvled3-used:
+High voltage backlight strings configuration. Type is .
+Please describe which output backlight string is used.
+Please refer to the datasheets [3].


Use led-sources.


OK.




+
+  Optional properties of a child node:
+  - backlight-name: Name string for backlight device identification.
+It is used for creating backlight sysfs,
+/sys/class/backlight//.


Use label.


Got it.




+  - backlight-max-microamp: Max current setting. Type is .
+Unit is microampere.
+Range is from 5000 to 3.


Use led-max-microamp


OK.




+  - initial-brightness: Backlight initial brightness value. Type is .
+It is set as soon as backlight device is created.
+0 ~ 2047 = LM3631, LM3632, LM3633, LM3695 and LM3697
+0 ~ 255  = LM3532


Use default-brightness-level



I'll update the bindings and drivers based on your review. Many thanks!

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 03.11.2015 15:58, Pavel Fedin wrote:
>  Hello!
> 
> --- cut exynos5410.dtsi ---
>   sromc: sromc@1225 {
>   #address-cells = <2>;
>   #size-cells = <1>;
>   ranges = <0 0 0x0400 0x2
> 1 0 0x0500 0x2
> 2 0 0x0600 0x2
> 3 0 0x0700 0x2>;

 Do you have to use 2 cells for address? Cannot it be:
ranges = <0 0x0400 0x2
  1 0x0500 0x2
  2 0x0600 0x2
  3 0x0700 0x2>;
>>>
>>>  I tried this first, but it didn't work, and ranges translation
>>> gave me something really weird (like addr = 0x80 and
>>> size = 0x0404).
>>
>> Did you change the address-cells to <1>?
> 
>  Of course i did.

I saw some other nodes use the ranges without the offset but maybe some
more steps are required for such configuration.

So anyway send the version with the child offset and I will try to
figure out why it is required.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Dmitry Torokhov]

On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > +Required properties:
> > > + - compatible: "ti,tsc2004"
> > > + - interrupts: IRQ specifier
> > > + - vio-supply : Regulator specifier
> > 
> > reg property?
> 
> Rob,
> 
> It appears that I missed this in the description.
> 
> Probably because I was following the lead of the ts2005 description.
> 
> How does this look:
> - reg : I2C address. 0x48 - 0x4b based on the voltage applied 
> to
> the AD1 and AD0 inputs on the IC.
> 

How about the version below?

Thanks.

-- 
Dmitry


Input: tsc2004 - document ts2004 dt bindings

From: Michael Welling 

Adds documentation for the devicetree bindings of the new tsc2004 driver.

Signed-off-by: Michael Welling 
Signed-off-by: Dmitry Torokhov 
---
 .../bindings/input/touchscreen/tsc2005.txt |   34 
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
index 09089a6..b80c04b 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -1,14 +1,15 @@
-* Texas Instruments tsc2005 touchscreen controller
+* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
 
 Required properties:
- - compatible: "ti,tsc2005"
- - reg   : SPI device address
- - spi-max-frequency : Maximal SPI speed
+ - compatible: "ti,tsc2004" or "ti,tsc2005"
+ - reg   : Device address
  - interrupts: IRQ specifier
- - reset-gpios   : GPIO specifier
- - vio-supply : Regulator specifier
+ - spi-max-frequency : Maximum SPI clocking speed of the device
+   (for tsc2005)
 
 Optional properties:
+ - vio-supply: Regulator specifier
+ - reset-gpios   : GPIO specifier for the controller reset line
  - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
plates
in ohm (defaults to 280)
  - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
after
@@ -18,6 +19,27 @@ Optional properties:
 
 Example:
 
+ {
+   tsc2004@48 {
+   compatible = "ti,tsc2004";
+   reg = <0x48>;
+   vio-supply = <>;
+
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
+
+   touchscreen-fuzz-x = <4>;
+   touchscreen-fuzz-y = <7>;
+   touchscreen-fuzz-pressure = <2>;
+   touchscreen-size-x = <4096>;
+   touchscreen-size-y = <4096>;
+   touchscreen-max-pressure = <2048>;
+
+   ti,x-plate-ohms = <280>;
+   ti,esd-recovery-timeout-ms = <8000>;
+   };
+}
+
  {
tsc2005@0 {
compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 11/2/2015 11:33 AM, Arnd Bergmann wrote:

On Sunday 01 November 2015 13:50:53 Sinan Kaya wrote:



The issue is not writel_relaxed vs. writel. After I issue reset, I need
wait for some time to confirm reset was done. I can use readl_polling
instead of mdelay if we don't like mdelay.


I meant that both _relaxed() and mdelay() are probably wrong here.


You are right about redundant writel_relaxed + wmb. They are effectively
equal to writel.


Actually, writel() is wmb()+writel_relaxed(), not the other way round:


I agree. Semantics... but important one since order matters this time.



When sending a command to a device that can start a DMA transfer,
the barrier is required to ensure that the DMA happens after previously
written data has gone from the CPU write buffers into the memory that
is used as the source for the transfer.


Agreed.


A barrier after the writel() has no effect, as MMIO writes are posted
on the bus.


I had two use cases in the original code. We are talking about start 
routine here. I was giving reference to enable/reset/disable uses above.


1. Start routine
--
spin_lock
writel_relaxed
spin_unlock

and

2. enable/reset/disable
--
writel_relaxed
wmb

I changed writel_relaxed to writel now in start routine and submitted 
the second version of the patchset yesterday. I hope you have received 
it. I was relying on the spinlocks before.






However, after issuing the command; I still need to wait some amount of
time until hardware acknowledges the commands like reset/enable/disable.
These are relatively faster operations happening in microseconds. That's
why, I have mdelay there.

I'll take a look at workqueues but it could turn out to be an overkill
for few microseconds.


Most devices are able to provide an interrupt for long-running commands.
Are you sure that yours is unable to do this? If so, is this a design
mistake or an implementation bug?


I think I was not clear on how long these command take. These command 
are really fast and get acknowledged at status register in few 
microseconds. That's why I choose polling.


I was waiting up to 10ms before and manually sleeping 1 milliseconds in 
between each using mdelay. I followed your suggestion and got rid of the 
mdelay. Then, I used polled read command which calls the usleep_range 
function as you suggested.


Hardware supports error interrupts but this is a SW design philosophy 
discussion. Why would you want to trigger an interrupt for few 
microseconds delay that only happens during the first time init from probe?





Reading the status probably requires a readl() rather than readl_relaxed()
to guarantee that the DMA data has arrived in memory by the time that the
register data is seen by the CPU. If using readl_relaxed() here is a valid
and required optimization, please add a comment to explain why it works
and how much you gain.


I will add some description. This is a high speed peripheral. I don't
like spreading barriers as candies inside the readl and writel unless I
have to.

According to the barriers video, I watched on youtube this should be the
rule for ordering.

"if you do two relaxed reads and check the results of the returned
variables, ARM architecture guarantees that these two relaxed variables
will get observed during the check."

this is called implied ordering or something of that sort.


My point was a bit different: while it is guaranteed that the
result of the readl_relaxed() is observed in order, they do not
guarantee that a DMA from device to memory that was started by
the device before the readl_relaxed() has arrived in memory
by the time that the readl_relaxed() result is visible to the
CPU and it starts accessing the memory.


I checked with the hardware designers. Hardware guarantees that by the
time interrupt is observed, all data transactions in flight are
delivered to their respective places and are visible to the CPU. I'll
add a comment in the code about this.


I'm curious about this. Does that mean the device is not meant for
high-performance transfers and just synchronizes the bus before
triggering the interrupt?


HIDMA meaning, as you probably guessed, is high performance DMA. We had 
several name iterations in the company and this was the one that sticked.


I'm a SW person. I don't have the expertise to go deeper into HW design.
I'm following the programming document. It says coherency and guaranteed 
interrupt ordering. High performance can mean how fast you can move data 
from one location to the other one vs. how fast you can queue up 
multiple requests and get acks in response.


I followed a simple design here. HW can take multiple requests 
simultaneously and give me an ack when it is finished with interrupt.


If there are requests in flight, other requests will get queued up in SW 
and will not be serviced until the previous requests get acknowledged. 
Then, as soon as HW stops processing; I queue a bunch of other requests 
and kick start it. 

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Stephen Boyd]

On 10/31, Viresh Kumar wrote:
> On 30-10-15, 14:49, Stephen Boyd wrote:
> > I suppose if you wanted to have 64 possible combinations of some
> > attribute you would just extend it to two 32 bit numbers in
> > sequence? I don't see the limitation here, and hopefully there
> > isn't a limitation so that we can specify sufficiently large
> > numbers with more bits if we need to.
> 
> Yeah, we discussed this earlier when Lee had the same query and I
> suggested the exact same thing to him then.
> 

Ah I see that after looking at the previous thread. Perhaps we
can add such information into the documentation so that people
aren't misled into thinking they're limited to 32 bits?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Andrew F. Davis]

On 11/01/2015 02:52 PM, Jonathan Cameron wrote:

On 31/10/15 16:31, Andrew F. Davis wrote:

Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
This device detects reflected LED light fluctuations and presents an ADC
value to the user space for further signal processing.

Data sheet located here:
http://www.ti.com/product/AFE4404/datasheet

Signed-off-by: Andrew F. Davis 

Hi Andrew,

Good to see this resurface.  It's a fascinating little device.

Anyhow, most of the interesting bit in here is unsuprisingly concerned
with the interface.  I know we went round a few loops of this before but
it still feels like we haven't worked out to handle it well.  I would like
as much input as we can get on this as inevitablly it will have
repercussions outside this driver.

Your approach of hammering out descriptive sysfs attributes is a good
starting point but we need to work towards a formal description that
can be generalised.  Whilst there are not many similar devices out there
to this one, I suspect there are a few and more may well show up in
future.



Yeah, I'm working on brining up drivers for them now :)


The escence of my rather roundabout response inline is that I'm suggesting
adding a new channel type to represent light transmission, taking the analogous
case of proximity devices in which we are looking at light reflection.
I've also taken the justification we use for illuminance vs intensity readings
for two sensor ALS sensors as a precident for having compound channels of a 
different
type to the 'raw' data that feeds them.  Hence I propose something along
the lines of:

in_intensityX_raw (raw channel value with the led on)
in_intensityX_ambient_raw (raw channel value with the led off)



I'm not sure, I know it may be too late for a lot of drivers but putting the 'X'
against the 'intensity' works for devices like ADCs/DACs with a simple list
of numeric channels, but for any other device with named channels this will
become very inconsistent, especially when adding modified channels and
differential channels.

For example:

in_intensity5_name_ambient-2_mean_raw

This is the differential of name and an unnamed channel '2', also something
is an average, is it channel '2', is it the whole differential channel? Is
5 this channels id or part of the first differential channel name? Who knows!

The way I would do it is with this more universal format:

[direction]_[type]_[name|number]_[info]


And then we just drop trying to deal with modifiers and differential stuff
internally, just let the driver give the channel a name with those. We then
wouldn't need to deal with channels numbers ether, just names.

struct iio_chan_spec {
enum iio_chan_type  type;

const char  *name;

unsigned long   address;
int scan_index;
struct {
charsign;
u8  realbits;
u8  storagebits;
u8  shift;
u8  repeat;
enum iio_endian endianness;
} scan_type;
const struct iio_event_spec *event_spec;
unsigned intnum_event_specs;
const struct iio_chan_spec_ext_info *ext_info;
const char  *datasheet_name;
unsignedoutput:1;
};

ADCs with lists of numeric channels would then not need to assign to channel
and set indexed, just set name = "3".

in_voltage_0_raw
in_voltage_1_raw
in_voltage_2_raw
etc..

Differential would become:

in_voltage_0-1_raw
in_voltage_2-6_raw
etc..

Again this might be too late to change for some existing drivers, but for
new ones nothing is really stoping this.


in_intensitytransmittedX_raw the differential signal which is actually just
measuring the proportion of light that got through the finger or similar.
(other naming suggestions welcome!)



As above, why keep patching the framework, let the drivers set the names,
I would have:

name = "led1-led1_ambient";

so:

in_intensity_led1-led1_ambient_raw

which would match the data sheet and match the names of the channels
that these are differencing on ("led1" and "led1_ambient").


Lots more detail inline, but I wanted anyone at a quick glance to know
what we are discussing.  Perhaps my suggestion is bonkers so feel free
to pick it to shreds.

The average channels are also unusual to handle.  When would a user
want to get both the average and non average channel via the triggered
buffer?   I propose that we might handle these generically by treating
the averaging process as a filter and extending the filter interface to
describe it.



Maybe they want one for display and let the hardware do the filtering on
the other? IDK

The end user my not need them both at the same time, but I see no reason
to limit them from using them if the want and keeping them as channels
like in the data sheet to avoid confusion.


I also do feel that the modularity you have driven for 

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Stephen Boyd]

On 10/31, Viresh Kumar wrote:
> On 30-10-15, 15:18, Stephen Boyd wrote:
> 
> > Also, this makes it sound like opp-supported-hw is really just
> > telling us if this is a supported frequency or not for the
> > particular device we're running on.
> 
> That's right.
> 
> > The current wording makes it
> 
> Of the commit log ? Or the way the nodes are written?

The way the documentation is written.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

[Arnd Bergmann]

On Monday 02 November 2015 17:03:58 John Garry wrote:
> >
> > Can do. Actually sg_req seems only ever has one element:
> > expander.c, smp_execute_task()
> > sg_init_one(>smp_task.smp_req, req, req_size);
> >
> >
> I tried replacing with dma_map_single, but I feel the code is not as 
> clean as I need to manually set sg_dma_len() and sg_dma_address():
>  req_len = sg_dma_len(sg_req) = sg_req->length;
>  sg_dma_address(sg_req) = dma_map_single(dev, sg_virt(sg_req),
>  req_len, DMA_TO_DEVICE);
>  if (dma_mapping_error(dev, sg_dma_address(sg_req)))
>   return -ENOMEM;
> sg_dma_address(sg_req) is used in another function for unmap.
> 
> opinion?
> 

What I meant was not using a struct scatterlist at all:
replace the 'sg_req' variable with a normal pointer, and then
do

hdr->cmd_table_addr = cpu_to_le64(dma_map_single(dev, req, len, 
DMA_TO_DEVICE));

Any reason this won't work?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] devicetree: add Sigma Designs vendor prefix

[Rob Herring]

On Mon, Nov 2, 2015 at 3:42 AM, Mason  wrote:
> On 02/10/2015 19:21, Mans Rullgard wrote:
>
>> Add the "sigma" vendor prefix for Sigma Designs, Inc.
>>
>> Signed-off-by: Mans Rullgard 
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 82d2ac9..ea77ee5 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -192,6 +192,7 @@ schindler Schindler
>>  seagate  Seagate Technology PLC
>>  semtech  Semtech Corporation
>>  sharpSharp Corporation
>> +sigmaSigma Designs, Inc.
>>  sil  Silicon Image
>>  silabs   Silicon Laboratories
>>  siliconmitus Silicon Mitus, Inc.
>
> Hello,
>
> How can I determine whether this patch has been applied?
>
> (I examined a few branches in Rob's tree.)

I've now applied it.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Kim, Milo]

Hi Rob,

On 11/2/2015 11:53 PM, Rob Herring wrote:

On Sun, Nov 1, 2015 at 11:01 PM, Milo Kim  wrote:

LM3633 LED device is one of TI LMU device list.

Cc: devicetree@vger.kernel.org
Cc: Jacek Anaszewski 
Cc: Lee Jones 
Cc: linux-ker...@vger.kernel.org
Cc: linux-l...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  .../devicetree/bindings/leds/leds-lm3633.txt   | 28 ++
  1 file changed, 28 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..bb7f213
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,28 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+  - compatible: "ti,lm3633-leds"
+
+Child nodes:
+  Each node matches with LED control bank.
+  Please refer to the datasheet [1].
+
+  Required properties of a child node:
+  - lvled1-used, lvled2-used, lvled3-used,
+lvled4-used, lvled5-used, lvled6-used:
+Low voltage LED string configuration. Type is .
+Please describe which output LED string is used.


What is "LED string"?


Let me replace these properties with 'led-sources'.



We have properties for which LED driver/channel of the parent to use
and "status" can be used to disable child nodes.


+
+  Optional properties of a child node:
+  - channel-name: Name string for LED channel identification
+  It is used for creating LED sysfs,
+  /sys/class/leds//.
+  If this property is empty, then default name is set to
+  "indicator:" by the driver.


I believe "label" already provides this function.



Yep, got it. Thanks!

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Kim, Milo]

Hi Lee,

On 11/2/2015 6:00 PM, Lee Jones wrote:

Is it just me, or have you missed lots of people off Cc?


Ah, that's what I was hesitating...
What is the best way to submit MFD code patches? Cc for all people from 
get_maintainer.pl?


Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

 Hello!

> >>> --- cut exynos5410.dtsi ---
> >>>   sromc: sromc@1225 {
> >>>   #address-cells = <2>;
> >>>   #size-cells = <1>;
> >>>   ranges = <0 0 0x0400 0x2
> >>> 1 0 0x0500 0x2
> >>> 2 0 0x0600 0x2
> >>> 3 0 0x0700 0x2>;
> >>
> >> Do you have to use 2 cells for address? Cannot it be:
> >>ranges = <0 0x0400 0x2
> >>  1 0x0500 0x2
> >>  2 0x0600 0x2
> >>  3 0x0700 0x2>;
> >
> >  I tried this first, but it didn't work, and ranges translation
> > gave me something really weird (like addr = 0x80 and
> > size = 0x0404).
> 
> Did you change the address-cells to <1>?

 Of course i did.

 I don't quote the rest because i simply agree to what you've said. Will respin 
with these changes.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 14/16] hwmon: add TI LMU hardware fault monitoring driver

[Kim, Milo]

Hi Guenter,

On 11/2/2015 11:27 PM, Guenter Roeck wrote:

On 11/01/2015 09:24 PM, Milo Kim wrote:

LM3633 and LM3697 are TI LMU MFD device.
Those device have hardware monitoring feature which detects opened or
shorted circuit case.


Sure, but it only makes sense if you provide standard hwmon attributes
which can be interpreted by the "sensors" command. Which is not the case
here. You neither have a standard device type (light is not handled by hwmon),
nor standard attributes, nor do the attributes return standard values.

I think there may be a basic misunderstanding. hwmon is not intended
to monitor a specific chip on the board. Its scope is to monitor the
system (such as temperature, voltages, or current).

In your case, it might be better to attach the attributes to the mfd device.



OK, got your point. Thanks a lot for your suggestion.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 16/16] regulator: add LM363X driver

[Kim, Milo]

On 11/2/2015 9:26 PM, Mark Brown wrote:

On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:

LM363X regulator driver supports LM3631 and LM3632.
LM3631 has 5 regulators. LM3632 provides 3 regulators.
One boost output and LDOs are used for the display module.
Boost voltage is configurable but always on.
Supported operations for LDOs are enabled/disabled and voltage change.


As far as I can tell this is another partial resend of a series you
originally sent about 15 minutes previously - what's going on here?



My apologies, I did send patches without --thread and 
--no-chain-reply-to options. So I've resent the patch-set.


Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/2/2015 10:57 AM, Rob Herring wrote:

On Mon, Nov 2, 2015 at 12:07 AM, Sinan Kaya  wrote:

The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design. The management
driver is executed in hypervisor context and is the main
management entity for all channels provided by the device.
The channel driver is executed in the hypervisor/guest OS
context.

All channel devices get probed in the hypervisor
context during power up. They show up as DMA engine
channels. Then, before starting the virtualization; each
channel device is unbound from the hypervisor by VFIO
and assigned to the guest machine for control.

This management driver will be used by the system
admin to monitor/reset the execution state of the DMA
channels. This will be the management interface.

Signed-off-by: Sinan Kaya 
---
  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  56 ++
  drivers/dma/Kconfig|  11 +
  drivers/dma/Makefile   |   1 +
  drivers/dma/qcom_hidma_mgmt.c  | 747 +
  4 files changed, 815 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
  create mode 100644 drivers/dma/qcom_hidma_mgmt.c

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..514d37d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,56 @@
+Qualcomm Technologies HIDMA Management interface
+
+The Qualcomm Technologies HIDMA device has been designed
+to support virtualization technology. The driver has been
+divided into two to follow the hardware design. The management
+driver is executed in hypervisor context and is the main
+management entity for all channels provided by the device.


Let me try one more time. Hope this helps.

Each HIDMA HW consists of multiple channels. These channels share
some set of common parameters. These parameters are initialized
by the management driver during power up. Same management driver is used 
for monitoring the execution of the channels. Management driver

can change the performance behaviors dynamically such as bandwidth
allocation and prioritization.



This doesn't really explain what the block is.


+All channel devices get probed in the hypervisor
+context during power up. They show up as DMA engine
+DMA channels. Then, before starting the virtualization; each
+channel device is unbound from the hypervisor by VFIO
+and assign to the guest machine for control.
+
+This management driver will  be used by the system
+admin to monitor/reset the execution state of the DMA
+channels. This will be the management interface.
+
+
+Required properties:
+- compatible: must contain "qcom,hidma-mgmt"


Please make this more specific. It doesn't match your example either.
Unless "1.0" type versioning is tightly controlled and defined,
version numbers are usually not a good practice.


+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+  fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+  fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst


This would be a function of burst-bytes and bus width. Are you sure
you don't me number of outstanding transactions which is a common
parameter for AXI bus peripherals.



These are all the available HW knobs for performance at this moment. 
max-write-transactions corresponds to the max number of outstanding 
transactions.



+- channel-reset-timeout: Channel reset timeout for this SOC.


Please add units to property name.


ok, changed to channel-reset-timeout-cycles




+- channel-priority: Priority of the channel.
+  Each dma channel share the same HW bandwidth with other dma channels.
+  If two requests reach to the HW at the same time from a low priority and
+  high priority channel, high priority channel will claim the bus.
+  0=low priority, 1=high priority
+- channel-weight: Round robin weight of the channel
+  Since there are only two priority levels supported, scheduling among
+  the equal priority channels is done via weights.
+
+Example:
+
+   hidma-mgmt@f9984000 = {
+   compatible = "qcom,hidma-mgmt-1.0";
+   reg = <0xf9984000 0x15000>;
+   dma-channels = 6;
+   max-write-burst-bytes = 1024;
+   max-read-burst-bytes = 1024;
+   max-write-transactions = 31;
+   max-read-transactions = 31;
+   channel-reset-timeout = 

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 11/2/2015 3:55 PM, Arnd Bergmann wrote:

Are you using message signaled interrupts then?
Typically MSI guarantees
ordering against DMA, but level or edge triggered interrupts by definition
cannot (at least on PCI, but most other buses are the same way), because
the DMA master has no insight into when a DMA is actually complete.

If you use MSI, please add a comment to the readl_relaxed() that it
is safe because of that, otherwise the next person who tries to debug
a problem with your driver has to look into this.


No, using regular GIC SPI interrupts at this moment. I know that HW 
doesn't use any of the typical AHB/AXI ARM buses.


I'm familiar with how PCI endpoints works. While the first read in a 
typical PCI endpoint ISR flushes all outstanding requests traditionally 
to the destination, this concept does not apply here for this HW.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288

[Zain Wang]

Add Crypto drivers for rk3288 including crypto controller and dma clk.

Signed-off-by: Zain Wang 
---
 arch/arm/boot/dts/rk3288.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..7b7914e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,21 @@
};
};
 
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,rk3288-crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SCLK_CRYPTO>,
+< ACLK_DMAC1>;
+   clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+   status = "okay";
+   };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain Wang]

Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
mode.
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.

And other algorithms and platforms will be added later on.

Signed-off-by: Zain Wang 
---
 drivers/crypto/Kconfig |  11 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rockchip/Makefile   |   3 +
 drivers/crypto/rockchip/rk3288_crypto.c| 383 
 drivers/crypto/rockchip/rk3288_crypto.h| 290 
 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 +
 6 files changed, 1189 insertions(+)
 create mode 100644 drivers/crypto/rockchip/Makefile
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..d1e42cf 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
  To compile this driver as a module, choose M here: the module
  will be called sun4i-ss.
 
+config CRYPTO_DEV_ROCKCHIP
+   tristate "Rockchip's Cryptographic Engine driver"
+
+   select CRYPTO_AES
+   select CRYPTO_DES
+   select CRYPTO_BLKCIPHER
+
+   help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..02830f2
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,383 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct crypto_info_t *crypto_p;
+
+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
+{
+   int err;
+
+   err = clk_prepare_enable(dev->sclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
+   __func__, __LINE__);
+   goto err_return;
+   }
+   err = clk_prepare_enable(dev->aclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+   __func__, __LINE__);
+   goto err_aclk;
+   }
+   err = clk_prepare_enable(dev->hclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+   __func__, __LINE__);
+   goto err_hclk;
+   }
+
+   err = clk_prepare_enable(dev->dmaclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
+   __func__, __LINE__);
+   goto err_dmaclk;
+   }
+   return err;
+err_dmaclk:
+   clk_disable_unprepare(dev->hclk);
+err_hclk:
+   clk_disable_unprepare(dev->aclk);
+err_aclk:
+   clk_disable_unprepare(dev->sclk);
+err_return:
+   return err;
+}
+
+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
+{
+   clk_disable_unprepare(dev->dmaclk);
+   clk_disable_unprepare(dev->hclk);
+   clk_disable_unprepare(dev->aclk);
+   clk_disable_unprepare(dev->sclk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+  struct scatterlist *sg_dst,
+  int align_mask)
+{
+   int in, out, align;
+
+   in = IS_ALIGNED((uint32_t)sg_src->offset, 4) &&
+

[PATCH v1 0/4] Crypto: add crypto accelerator support for rk3288

[Zain Wang]

This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc),
and the more algorithms and new hash drivers will be added later on.

Zain Wang (4):
  Crypto: Crypto driver support aes/des/des3 for rk3288
  clk: rockchip: set an id for crypto clk
  ARM: dts: rockchip: Add Crypto drivers for rk3288
  crypto: rk_crypto - add DT bindings documentation

 .../devicetree/bindings/crypto/rockchip-crypto.txt |  29 ++
 arch/arm/boot/dts/rk3288.dtsi  |  15 +
 drivers/clk/rockchip/clk-rk3288.c  |   2 +-
 drivers/crypto/Kconfig |  11 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rockchip/Makefile   |   3 +
 drivers/crypto/rockchip/rk3288_crypto.c| 383 
 drivers/crypto/rockchip/rk3288_crypto.h| 290 
 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 +
 include/dt-bindings/clock/rk3288-cru.h |   1 +
 10 files changed, 1235 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
 create mode 100644 drivers/crypto/rockchip/Makefile
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c

-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 4/4] crypto: rk_crypto - add DT bindings documentation

[Zain Wang]

Add DT bindings documentation for the rk3288 crypto drivers.

Signed-off-by: Zain Wang 
---
 .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt 
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..d27e203
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: base physical address of the engine and length of memory mapped
+   region
+- interrupts: interrupt number
+- clocks: reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+  "hclk" used to clock data
+  "srst" used to clock crypto accelerator
+  "apb_pclk" used to clock dma
+
+Examples:
+
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,rk3288-crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SCLK_CRYPTO>,
+< ACLK_DMAC1>;
+   clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+   status = "okay";
+   };
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 2/4] clk: rockchip: set an id for crypto clk

[Zain Wang]

set an id for crypto clk, so that it can be called in other part.

Signed-off-by: Zain Wang 
---
 drivers/clk/rockchip/clk-rk3288.c  | 2 +-
 include/dt-bindings/clock/rk3288-cru.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_CRYPTO125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/4] Add support for STM32 DMA

[M'boumba Cedric Madianga]

 Hi Vinod,

Do you have any further comments or suggestions on this serie ?

BR,
Cedric

2015-10-16 15:59 GMT+02:00 M'boumba Cedric Madianga :
> This patchset adds support for the STM32 DMA controller.
> This controller provides 8 channels dedicated to managing memory access
> request from one or more peripherals.
> Each stream can have up to 8 requests in total.
>
> Changes since v3:
>  - Fix regression introduced in v3 during request channel
>  - Fix regression introduced in v3 for cyclic mode dma transfer
>  - update interrupt description in DT
>  - remove half transfer interrupt management as client callback as to be
>called only for complete transfer
>
> Changes since v2:
>  - remove interrupt configuration management from DT (Mark)
>  - remove FIFO configuration management from DT except threshold as it is very
>hard to handle it in the driver due to many possible combinations according
>to burst and bus width (Mark)
>  - update DMA client message in DT documentation file
>  - specify the order to be used to set per-channel DMA interrupts in the DT
>(Mark)
>  - remove unused enumerations for channel and request ids (Daniel)
>  - keep as soon as possible 80 lines char for more readability (Vinod)
>  - replace unsigned int by u32 (Vinod)
>  - use GFP_NOWAIT instead of GFP_ATOMIC during dma descriptors allocation
>(Vinod)
>  - return error if burst is not supported in stm32_dma_get_burst() (Vinod)
>  - return error if bus_width is not supported in stm32_dma_get_width() (Vinod)
>  - add FIFO configuration management inside the driver except for threshold
>  - add interrupt configuration management inside the driver (Mark)
>  - rework stm32_dma_chan_irq() to handle error interrupt in one way (Vinod)
>  - rework stm32_dma_set_xfer_param() to be easier to read
>  - update stm32_dma_tx_status() to always return status from 
> dma_cookie_status() (Vinod)
>  - disable clk if we don't manage to stop the DMA channel during channel
>resources allocation (Daniel)
>  - set driver as built-in as DMA will be required by other built-in driver
>
>  Changes since v1:
>   - remove dmamux boolean as it is not needed
>   - replace dma by DMA in Kconfig (Maxime)
>   - add default return value in stm32_dma_get_width()
>   - add defalut return value in stm32_dma_get_burst()
>   - use lower case for constant hexadecimal values (Maxime)
>
> M'boumba Cedric Madianga (4):
>   dt-bindings: Document the STM32 DMA bindings
>   dmaengine: Add STM32 DMA driver
>   ARM: dts: Add STM32 DMA support for STM32F429 MCU
>   ARM: configs: Add STM32 DMA support in STM32 defconfig
>
>  .../devicetree/bindings/dma/stm32-dma.txt  |   82 ++
>  arch/arm/boot/dts/stm32f429.dtsi   |   31 +
>  arch/arm/configs/stm32_defconfig   |2 +
>  drivers/dma/Kconfig|   12 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/stm32-dma.c| 1141 
> 
>  6 files changed, 1269 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
>  create mode 100644 drivers/dma/stm32-dma.c
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain]

Hi Stephan,

On 2015年10月30日 16:59, Stephan Mueller wrote:
> Am Freitag, 30. Oktober 2015, 16:22:46 schrieb Zain Wang:
>
> Hi Zain,
>
>> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
>> mode. The names registered are:
>>ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>> You can alloc tags above in your case.
>>
>> And other algorithms and platforms will be added later on.
>>
>> Signed-off-by: Zain Wang 
>> ---
>> drivers/crypto/Makefile|   1 +
>> drivers/crypto/rk_crypto/Makefile  |   3 +
>> drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>> drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>> .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502
>> + 5 files changed, 1190 insertions(+)
>> create mode 100644 drivers/crypto/rk_crypto/Makefile
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>>
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c3ced6f..00d103c 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>> obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>> obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>> diff --git a/drivers/crypto/rk_crypto/Makefile
>> b/drivers/crypto/rk_crypto/Makefile new file mode 100644
>> index 000..0f62d87
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>> +rk_crypto_driver-objs := rk3288_crypto.o \
>> + rk3288_crypto_ablkcipher.o \
>> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c
>> b/drivers/crypto/rk_crypto/rk3288_crypto.c new file mode 100644
>> index 000..fe55d7e
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> @@ -0,0 +1,393 @@
>> +/*
>> + *Crypto acceleration support for Rockchip RK3288
>> + *
>> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * Author: Zain Wang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>> + */
>> +
>> +#include "rk3288_crypto.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct crypto_info_t *crypto_p;
>> +
>> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>> +{
>> +if (clk_prepare_enable(dev->clk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>> +__func__, __LINE__);
>> +return -ENOENT;
>> +}
>> +if (clk_prepare_enable(dev->aclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>> +__func__, __LINE__);
>> +goto err_aclk;
>> +}
>> +if (clk_prepare_enable(dev->hclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>> +__func__, __LINE__);
>> +goto err_hclk;
>> +}
>> +if (clk_prepare_enable(dev->pclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>> +__func__, __LINE__);
>> +goto err_pclk;
>> +}
>> +return 0;
>> +
>> +err_pclk:
>> +clk_disable_unprepare(dev->hclk);
>> +err_hclk:
>> +clk_disable_unprepare(dev->aclk);
>> +err_aclk:
>> +clk_disable_unprepare(dev->clk);
>> +
>> +return -ENOENT;
>> +}
>> +
>> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>> +{
>> +clk_disable_unprepare(dev->hclk);
>> +clk_disable_unprepare(dev->aclk);
>> +clk_disable_unprepare(dev->pclk);
>> +clk_disable_unprepare(dev->clk);
>> +}
>> +
>> +static int check_alignment(struct scatterlist *sg_src,
>> +   struct scatterlist *sg_dst,
>> +   int align_mask)
>> +{
>> +int in, out, align;
>> +
>> +in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>> + IS_ALIGNED(sg_src->length, align_mask);
>> +if (sg_dst == NULL)
>> +return in;
>> +out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>> +  IS_ALIGNED(sg_dst->length, align_mask);
>> +align = in && out;
>> +
>> +return (align && (sg_src->length == sg_dst->length));
>> +}
>> +
>> +static int rk_load_data(struct crypto_info_t *dev,
>> +  struct scatterlist *sg_src,
>> +  struct 

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain]

Hi LABBE,

On 2015年10月30日 16:58, LABBE Corentin wrote:
> On Fri, Oct 30, 2015 at 04:22:46PM +0800, Zain Wang wrote:
>> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher 
>> mode.
>> The names registered are:
>> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>> You can alloc tags above in your case.
>>
>> And other algorithms and platforms will be added later on.
>>
>> Signed-off-by: Zain Wang 
>> ---
>>  drivers/crypto/Makefile|   1 +
>>  drivers/crypto/rk_crypto/Makefile  |   3 +
>>  drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>>  drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>>  .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 
>> +
>>  5 files changed, 1190 insertions(+)
>>  create mode 100644 drivers/crypto/rk_crypto/Makefile
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>>
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c3ced6f..00d103c 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>> diff --git a/drivers/crypto/rk_crypto/Makefile 
>> b/drivers/crypto/rk_crypto/Makefile
>> new file mode 100644
>> index 000..0f62d87
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>> +rk_crypto_driver-objs := rk3288_crypto.o \
>> + rk3288_crypto_ablkcipher.o \
>> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
>> b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> new file mode 100644
>> index 000..fe55d7e
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> @@ -0,0 +1,393 @@
>> +/*
>> + *Crypto acceleration support for Rockchip RK3288
>> + *
>> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * Author: Zain Wang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>> + */
>> +
>> +#include "rk3288_crypto.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct crypto_info_t *crypto_p;
>> +
>> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>> +{
>> +if (clk_prepare_enable(dev->clk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>> +__func__, __LINE__);
>> +return -ENOENT;
>> +}
>> +if (clk_prepare_enable(dev->aclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>> +__func__, __LINE__);
>> +goto err_aclk;
>> +}
>> +if (clk_prepare_enable(dev->hclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>> +__func__, __LINE__);
>> +goto err_hclk;
>> +}
>> +if (clk_prepare_enable(dev->pclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>> +__func__, __LINE__);
>> +goto err_pclk;
>> +}
>> +return 0;
>> +
>> +err_pclk:
>> +clk_disable_unprepare(dev->hclk);
>> +err_hclk:
>> +clk_disable_unprepare(dev->aclk);
>> +err_aclk:
>> +clk_disable_unprepare(dev->clk);
>> +
>> +return -ENOENT;
>> +}
> Please return the error value given by clk_prepare_enable()
ok! done!
>
>> +
>> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>> +{
>> +clk_disable_unprepare(dev->hclk);
>> +clk_disable_unprepare(dev->aclk);
>> +clk_disable_unprepare(dev->pclk);
>> +clk_disable_unprepare(dev->clk);
>> +}
>> +
>> +static int check_alignment(struct scatterlist *sg_src,
>> +   struct scatterlist *sg_dst,
>> +   int align_mask)
>> +{
>> +int in, out, align;
>> +
>> +in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>> + IS_ALIGNED(sg_src->length, align_mask);
>> +if (sg_dst == NULL)
>> +return in;
>> +out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>> +  IS_ALIGNED(sg_dst->length, align_mask);
>> +align = in && out;
>> +
>> +return (align && (sg_src->length == sg_dst->length));
>> +}
>> +
>> +static int rk_load_data(struct crypto_info_t *dev,
>> +  

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Viresh Kumar]

On 02-11-15, 09:13, Rob Herring wrote:
> There is no special meaning, just convention which is the unit-address
> should match the reg property address. I'm okay with an exception
> here.

Thanks, I will update this separately.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor

[Andrew F. Davis]

On 10/31/2015 01:44 PM, Rob Herring wrote:

gmail thinks this is spam BTW.



Strange, the mailing lists do too.


On Sat, Oct 31, 2015 at 11:31 AM, Andrew F. Davis  wrote:

Add the TI afe4404 heart monitor DT bindings documentation.
Create health directory created under iio.

Signed-off-by: Andrew F. Davis 
---
  .../devicetree/bindings/iio/health/afe4404.txt | 27 ++
  1 file changed, 27 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4404.txt

diff --git a/Documentation/devicetree/bindings/iio/health/afe4404.txt 
b/Documentation/devicetree/bindings/iio/health/afe4404.txt
new file mode 100644
index 000..d377033
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/afe4404.txt
@@ -0,0 +1,27 @@
+* Texas Instruments AFE4404 Heart rate and Pulse Oximeter
+
+Required properties:
+ - compatible  : Should be "ti,afe4404".
+ - reg : I2C address of the device.
+ - led-supply  : Regulator supply to the device.


Is led correct name or copy-n-paste? The datasheet has tx_sup and
rx_sup for supplies.



Looking back at the data sheet it looks like it also has an io_sup.
rx_sup seems to be the supply that must be on to keep the device on.
io_sup and tx_sup can be disabled without losing register values and
reseting the device.

I'm not sure if it makes sense to list the needed supplies, so I may
just rename led-supply to tx_sup-supply and have the be the only one.


+ - interrupt-parent: Phandle to he parent interrupt controller.
+ - interrupts  : The interrupt line the device ADC_RDY pin is 
connected to.
+
+Optional properties:
+ - reset-gpios : GPIO used to reset the device.
+
+Example:
+
+ {
+   heart_mon@58 {
+   compatible = "ti,afe4404";
+   reg = <0x58>;
+
+   led-supply = <>;
+
+   interrupt-parent = <>;
+   interrupts = <28 IRQ_TYPE_EDGE_RISING>;
+
+   reset-gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+};
--
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] PCI: pcie-rcar: Add support for R-Car H3.

[Phil Edworthy]

From: Harunobu Kurokawa 

R-Car H3 device is r8a7795

Signed-off-by: Harunobu Kurokawa 
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 3 ++-
 drivers/pci/host/pcie-rcar.c   | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 29d3b98..ab2e75f 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -2,7 +2,8 @@
 
 Required properties:
 - compatible: should contain one of the following
-   "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+   "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791",
+   "renesas,pcie-r8a7795"
 - reg: base address and length of the pcie controller registers.
 - #address-cells: set to <3>
 - #size-cells: set to <2>
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 27c0521..2377bf0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -917,6 +917,7 @@ static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
+   { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
{},
 };
 MODULE_DEVICE_TABLE(of, rcar_pcie_of_match);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] panel/panasonic-vvx10f034n00: Add DT bindings

[Rob Herring]

On Fri, Oct 30, 2015 at 7:38 PM,   wrote:
> From: Werner Johansson 
>
> This patch adds bindings for the Panasonic VVX10F034N00
> WUXGA panel.
>
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 

Acked-by: Rob Herring 

> ---
>  .../bindings/panel/panasonic,vvx10f034n00.txt| 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt 
> b/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
> new file mode 100644
> index 000..37dedf6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
> @@ -0,0 +1,20 @@
> +Panasonic 10" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "panasonic,vvx10f034n00"
> +- reg: DSI virtual channel of the peripheral
> +- power-supply: phandle of the regulator that provides the supply voltage
> +
> +Optional properties:
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> +   mdss_dsi@fd922800 {
> +   panel@0 {
> +   compatible = "panasonic,vvx10f034n00";
> +   reg = <0>;
> +   power-supply = <_vsp>;
> +   backlight = <_wled>;
> +   };
> +   };
> --
> 2.3.2 (Apple Git-55)
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Rob Herring]

On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson  wrote:
> From: Doug Anderson 
>
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).

I would think re-enumerating means autosuspend is broken.

> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
>
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit), which does a more full
> reset.  The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).

The reset from the CRU goes to the PHY, correct? Therefore, the
binding should reflect that. Connecting it to the host controller is a
hack.

So describe the reset connection properly and then add a .phy_reset()
hook to the phy subsystem. Then call that when flag property you added
is set.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Sunday 01 November 2015 13:50:53 Sinan Kaya wrote:
> 
> >> The issue is not writel_relaxed vs. writel. After I issue reset, I need
> >> wait for some time to confirm reset was done. I can use readl_polling
> >> instead of mdelay if we don't like mdelay.
> >
> > I meant that both _relaxed() and mdelay() are probably wrong here.
> 
> You are right about redundant writel_relaxed + wmb. They are effectively 
> equal to writel.

Actually, writel() is wmb()+writel_relaxed(), not the other way round:

When sending a command to a device that can start a DMA transfer,
the barrier is required to ensure that the DMA happens after previously
written data has gone from the CPU write buffers into the memory that
is used as the source for the transfer.

A barrier after the writel() has no effect, as MMIO writes are posted
on the bus.

> However, after issuing the command; I still need to wait some amount of 
> time until hardware acknowledges the commands like reset/enable/disable. 
> These are relatively faster operations happening in microseconds. That's 
> why, I have mdelay there.
> 
> I'll take a look at workqueues but it could turn out to be an overkill 
> for few microseconds.

Most devices are able to provide an interrupt for long-running commands.
Are you sure that yours is unable to do this? If so, is this a design
mistake or an implementation bug?

> >>> Reading the status probably requires a readl() rather than readl_relaxed()
> >>> to guarantee that the DMA data has arrived in memory by the time that the
> >>> register data is seen by the CPU. If using readl_relaxed() here is a valid
> >>> and required optimization, please add a comment to explain why it works
> >>> and how much you gain.
> >>
> >> I will add some description. This is a high speed peripheral. I don't
> >> like spreading barriers as candies inside the readl and writel unless I
> >> have to.
> >>
> >> According to the barriers video, I watched on youtube this should be the
> >> rule for ordering.
> >>
> >> "if you do two relaxed reads and check the results of the returned
> >> variables, ARM architecture guarantees that these two relaxed variables
> >> will get observed during the check."
> >>
> >> this is called implied ordering or something of that sort.
> >
> > My point was a bit different: while it is guaranteed that the
> > result of the readl_relaxed() is observed in order, they do not
> > guarantee that a DMA from device to memory that was started by
> > the device before the readl_relaxed() has arrived in memory
> > by the time that the readl_relaxed() result is visible to the
> > CPU and it starts accessing the memory.
> >
> I checked with the hardware designers. Hardware guarantees that by the 
> time interrupt is observed, all data transactions in flight are 
> delivered to their respective places and are visible to the CPU. I'll 
> add a comment in the code about this.

I'm curious about this. Does that mean the device is not meant for
high-performance transfers and just synchronizes the bus before
triggering the interrupt?

> > In other words, when the hardware sends you data followed by an
> > interrupt to tell you the data is there, your interrupt handler
> > can tell the driver that is waiting for this data that the DMA
> > is complete while the data itself is still in flight, e.g. waiting
> > for an IOMMU to fetch page table entries.
> >
> There is HW guarantee for ordering.
> 
> On demand paging for IOMMU is only supported for PCIe via PRI (Page 
> Request Interface) not for HIDMA. All other hardware instances work on 
> pinned DMA addresses. I'll drop a note about this too to the code as well.

I wasn't talking about paging, just fetching the IOTLB from the
preloaded page tables in RAM. This can takes several uncached memory
accesses, so it would generally be slow.


Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

[John Garry]

On 30/10/2015 16:22, John Garry wrote:

On 30/10/2015 13:53, Arnd Bergmann wrote:

On Monday 26 October 2015 22:14:58 John Garry wrote:


+   /*
+   * DMA-map SMP request, response buffers
+   */
+   /* req */
+   sg_req = >smp_task.smp_req;
+   elem = dma_map_sg(dev, sg_req, 1, DMA_TO_DEVICE);
+   if (!elem)
+   return -ENOMEM;
+   req_len = sg_dma_len(sg_req);
+   req_dma_addr = sg_dma_address(sg_req);


If you only use the first element, could you just use dma_map_single()?



Can do. Actually sg_req seems only ever has one element:
expander.c, smp_execute_task()
sg_init_one(>smp_task.smp_req, req, req_size);


I tried replacing with dma_map_single, but I feel the code is not as 
clean as I need to manually set sg_dma_len() and sg_dma_address():

req_len = sg_dma_len(sg_req) = sg_req->length;
sg_dma_address(sg_req) = dma_map_single(dev, sg_virt(sg_req),
 req_len, DMA_TO_DEVICE);
if (dma_mapping_error(dev, sg_dma_address(sg_req)))
 return -ENOMEM;
sg_dma_address(sg_req) is used in another function for unmap.

opinion?



___
linuxarm mailing list
linux...@huawei.com
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

.




cheers,
John

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Timur Tabi]

On 11/02/2015 10:20 AM, Sinan Kaya wrote:



Is there a good example I can look or a wiki about the device-tree
naming conventions?

I'm more of an ACPI person than DTS.


I think Rob is talking about something like this:

compatible="qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"

This specifies that this is the v1.0 of the HIDMA management engine (or, 
the management engine for the 1.0 HIDMA device).  That way, if in the 
future there's a v1.1, you can do this:


compatible="qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt"

The driver will probe only on ""qcom,hidma-mgmt", but in the probe 
function, it can query the version number and act accordingly.


Alternatively, the driver can probe on both:

static const struct of_device_id hidma_match[] = {
{ .compatible = "qcom,hidma-mgmt-1.0", _struct},
{ .compatible = "qcom,hidma-mgmt-1.1", _struct},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);

And then the probe function will automatically get a pointer to either 
v10_struct or v11_struct.


--
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Daniel Lezcano]

On 10/31/2015 12:47 AM, Heiko Stuebner wrote:

Hi Daniel,

Am Freitag, 30. Oktober 2015, 11:42:29 schrieb Daniel Lezcano:

On 10/30/2015 04:43 AM, Caesar Wang wrote:

Hi Daniel,

在 2015年10月01日 03:14, Heiko Stübner 写道:

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:

On 09/25/2015 04:14 AM, Caesar Wang wrote:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand
1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy" param
is the default which you are allow to omit, so on arm32 dsb()and
dsb(sy)
are the same.

Signed-off-by: Caesar Wang 

Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting them
to go
through the same tree as the devicetree changes, right?


I'm wonder if someone will apply this series patchs but the wait.:-)
In fact, I'm no sure that the Acked is really meaning.:-


Yes, by acking the patch I say I am ok with it and I agree it can go
through another tree.


although I guess the two clocksource changes could very well just go
through your tree. dsb() -> dsb(sy) is supposed to be equal and the second
one is just cosmetics.  The Kconfig and dts changes need to wait in any case
for 4.5 ... but I guess that may be true for the clocksource changes as well?


Heiko, Caesar,

I am wondering if the dsb() is really necessary. Is it possible you test 
the timer by removing this instruction ? Otherwise I will have to setup 
my board again and it will take awhile.



--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model

[Viresh Kumar]

On 02-11-15, 15:53, Punit Agrawal wrote:
> For dynamic power, I had posted some patches[0][1][2] introducing the
> binding as well as updating cooling device registration via cpufreq
> driver. Now that the SCPI hwmon driver is merged, I should re-send the
> remaining patches.
> 
> [0] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01020.html
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01022.html
> [3] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01031.html

Sure. Just that whatever can be merged with opp-v2 should be merged.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 31 October 2015 01:18
> To: Anup Patel
> Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland;
> Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; 
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
> 
> On Fri, Oct 30, 2015 at 12:29:20PM +0530, Anup Patel wrote:
> > Just like other NAND controllers,
> 
> ^^ That part isn't strictly true. While READ ID data only comes out on the 
> lower 8
> bits, that doesn't *actually* mean you can't get valid data from a 16-bit bus 
> in
> general; you just have to drop the upper 8 bits. That's what these two commits
> did for read ID and parameter page read commands:
> 
> commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
> Author: Brian Norris 
> Date:   Wed Jan 29 14:08:12 2014 -0800
> 
> mtd: nand: force NAND_CMD_READID onto 8-bit bus
> 
> commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
> Author: Brian Norris 
> Date:   Fri Nov 29 22:04:28 2013 -0800
> 
> mtd: nand: don't use read_buf for 8-bit ONFI transfers
> 
> > the NAND READID command only works
> > in 8bit mode for all versions of BRCMNAND controller.
> 
> But I presume *this* statement is actually true. This NAND controller doesn't
> exactly give us a fully-flexible READID / read_byte / read_word command, as it
> works at a higher level than that (although LOW_LEVEL_OP gives us this
> flexibility now). I could imagine (though I never tested 16-bit NAND) that 
> 16-bit
> READID is broken.
> 
> BTW, did you ask the HW designer about this? It'd be nice to be 100% sure.

Yes, we had a discussed with HW designers and they confirmed
that READID command will only work in 8bit mode.

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/2/2015 10:57 AM, Rob Herring wrote:

Please make this more specific. It doesn't match your example either.
Unless "1.0" type versioning is tightly controlled and defined,
version numbers are usually not a good practice.
Is there a good example I can look or a wiki about the device-tree 
naming conventions?


I'm more of an ACPI person than DTS.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 31 October 2015 01:02
> To: Anup Patel
> Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland;
> Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; 
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC
> 
> On Fri, Oct 30, 2015 at 12:29:18PM +0530, Anup Patel wrote:
> > We enable NAND support for Broadcom NS2 SoC by reusing existing
> > BRCMNAND driver.
> >
> > This patchset applies on-top of "arm64: Simple additions to
> > NS2 DT" v1 patchset and is available in ns2_nand_v5 branch of
> > https://github.com/Broadcom/arm64-linux.git.
> >
> > The patchset is tested on NS2 SVK.
> 
> Applied patches 1 and 2. My "Reviewed-by" on patch 3 stands.
> 

Thanks Brian.

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Andrew Bresticker]

Hi Fabio,

On Sun, Nov 1, 2015 at 5:55 AM, Fabio Estevam  wrote:
> Hi Andrew,
>
> On Mon, Mar 30, 2015 at 1:56 AM, Andrew Bresticker
>  wrote:
>
>>> I'd rather we have it defined explicitly in the binding, i.e. make it a
>>> required property?
>>
>> Sure, will do.
>
> Do you plan to send a v2 of the generic ADC keypad series?

We ended up not needing this driver, so I didn't send up a v2.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] dt-bindings: sound: Add DT bindings for Broadcom Cygnus audio

[Simran Rai]

Add bindings for audio driver in Broadcom Cygnus.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../bindings/sound/brcm,cygnus-audio.txt   |   63 
 1 file changed, 63 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt 
b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
new file mode 100644
index 000..73cddb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
@@ -0,0 +1,63 @@
+BROADCOM Cygnus Audio I2S/TDM/SPDIF controller
+
+Required properties:
+   - compatible : "brcm,cygnus-audio"
+   - #address-cells: 32bit valued, 1 cell.
+   - #size-cells:  32bit valued, 0 cell.
+   - reg : Should contain audio registers location and length
+   - reg-names: names of the registers listed in "reg" property
+   Valid names are "aud" and "i2s_in". "aud" contains a
+   set of DMA, I2S_OUT and SPDIF registers. "i2s_in" contains
+   a set of I2S_IN registers.
+   - clocks: PLL and leaf clocks used by audio ports
+   - clock-names: names of 3 leaf clocks used by audio ports
+   Valid names are "ch0_audio", "ch1_audio", "ch2_audio"
+   - interrupts: audio DMA interrupt number
+
+SSP Subnode properties:
+- reg: The index of ssp port interface to use
+   Valid value are 0, 1, 2, or 3 (for spdif)
+- channel-group: Surround sound grouping that controls which channel
+  outputs belong to a group, specifically useful in Multi-channel
+  Interfaces grouping of serial port. In multi-channel stereo, use
+  "2_0", in 3.1 multi-channel grouping, use "3_1" and in 5.1
+  multi-channel grouping, use "5_1".
+
+
+Example:
+   cygnus_audio: audio@180ae000 {
+   compatible = "brcm,cygnus-audio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x180ae000 0xafd>, <0x180aec00 0x1f8>;
+   reg-names = "aud", "i2s_in";
+   clocks = < BCM_CYGNUS_AUDIOPLL_CH0>,
+   < BCM_CYGNUS_AUDIOPLL_CH1>,
+   < BCM_CYGNUS_AUDIOPLL_CH2>;
+   clock-names = "ch0_audio", "ch1_audio", "ch2_audio";
+   interrupts = ;
+
+   ssp0: ssp_port@0 {
+   reg = <0>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   status = "okay";
+   };
+
+   ssp1: ssp_port@1 {
+   reg = <1>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   status = "disabled";
+   };
+
+   ssp2: ssp_port@2 {
+   reg = <2>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   status = "disabled";
+   };
+
+   spdif: spdif_port@3 {
+   reg = <3>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   status = "disabled";
+   };
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Arnd Bergmann]

On Saturday 31 October 2015 02:51:46 Sinan Kaya wrote:
> On 10/30/2015 5:34 AM, Arnd Bergmann wrote:
> > On Thursday 29 October 2015 23:08:12 Sinan Kaya wrote:
> >> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
> >> b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> >> +
> >> +static int qcom_hidma_mgmt_err_open(struct inode *inode, struct file 
> >> *file)
> >> +{
> >> +  return single_open(file, qcom_hidma_mgmt_err, inode->i_private);
> >> +}
> >> +
> >> +static const struct file_operations qcom_hidma_mgmt_err_fops = {
> >> +  .open = qcom_hidma_mgmt_err_open,
> >> +  .read = seq_read,
> >> +  .llseek = seq_lseek,
> >> +  .release = single_release,
> >> +};
> >> +
> >> +static ssize_t qcom_hidma_mgmt_mhiderr_clr(struct file *file,
> >> +  const char __user *user_buf, size_t count, loff_t *ppos)
> >> +{
> >> +  struct qcom_hidma_mgmt_dev *mgmtdev = file->f_inode->i_private;
> >> +
> >> +  HIDMA_RUNTIME_GET(mgmtdev);
> >> +  writel(1, mgmtdev->dev_virtaddr + MHID_BUS_ERR_CLR_OFFSET);
> >> +  HIDMA_RUNTIME_SET(mgmtdev);
> >> +  return count;
> >> +}
> >> +
> >> +static const struct file_operations qcom_hidma_mgmt_mhiderr_clrfops = {
> >> +  .write = qcom_hidma_mgmt_mhiderr_clr,
> >> +};
> >
> > Is this really just a debugging interface? If anyone would do this
> > for normal operation, it needs to be a proper API.
> >
> This will be used by the system admin to monitor/reset the execution 
> state of the DMA channels. This will be the management interface. 
> Debugfs is probably not the right choice. I originally had sysfs but 
> than had some doubts. I'm open to suggestions.

User interface design is unfortunately always hard, and I don't have
an obvious answer for you.

Using debugfs by definition means that you don't expect users to
rely on ABI stability, so they should not write any automated scripts
against the contents of the files.

With sysfs, the opposite is true: you need to maintain compatibility
for as long as anyone might rely on the current interface, and it
needs to be reviewed properly and documented in Documentation/ABI/.

Other options are to use ioctl(), netlink or your own virtual file
system, but each of them has the same ABI requirements as sysfs.

Regardless of what you pick, you also need to consider how other drivers
would use the same interface: If someone else has hardware that does
the same thing, we want to be able to use the same tools to access
it, so you should avoid having any hardware specific data in it and
keep it as generic and extensible as possible. In this particular
case, that probably means you should implement the user interfaces in
the dmaengine core driver, and let the specific DMA driver provide
callback function pointers along with the normal ones to fill that
data.

> >> +  dev_info(>dev,
> >> +  "HI-DMA engine management driver registration complete\n");
> >> +  platform_set_drvdata(pdev, mgmtdev);
> >> +  HIDMA_RUNTIME_SET(mgmtdev);
> >> +  return 0;
> >> +out:
> >> +  pm_runtime_disable(>dev);
> >> +  pm_runtime_put_sync_suspend(>dev);
> >> +  return rc;
> >> +}
> >
> > The rest of the probe function does not register any user interface aside 
> > from
> > the debugging stuff. Can you explain in the changelog how you expect the
> > driver to be used in a real system? Is there another driver coming?
> 
> I expect this driver to grow in functionality over time. Right now, it 
> does the global init for the DMA. After that all channels execute on 
> their own without depending on each other. Global init has to be done 
> first before attempting to do any channel initialization.
> 
> There is also implied startup ordering requirements. I was doing this by 
> using channel driver with the late binding to guarantee that.
> 
> As soon as I use module_platform_driver, the ordering gets reversed for 
> some reason.

For the ordering requirements, it's probably best to export a symbol
with the entry point and let the normal driver call into that. Using
separate initcall levels is not something you should do in a normal
device driver like this.

What is the relation between the device nodes for the two kinds of
devices? Does it make sense to model the other one as a child device
of this one? That way you would trivially do the ordering by not marking
this one as 'compatible="simple-bus"' and triggering the registration
of the child from the parent probe function.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Monday 02 November 2015 14:21:37 Sinan Kaya wrote:
> On 11/2/2015 11:33 AM, Arnd Bergmann wrote:
> > On Sunday 01 November 2015 13:50:53 Sinan Kaya wrote:
> > A barrier after the writel() has no effect, as MMIO writes are posted
> > on the bus.
> 
> I had two use cases in the original code. We are talking about start 
> routine here. I was giving reference to enable/reset/disable uses above.
> 
> 1. Start routine
> --
> spin_lock
> writel_relaxed
> spin_unlock
> 
> and
> 
> 2. enable/reset/disable
> --
> writel_relaxed
> wmb
> 
> I changed writel_relaxed to writel now in start routine and submitted 
> the second version of the patchset yesterday. I hope you have received 
> it. I was relying on the spinlocks before.

Ok

> >
> >> However, after issuing the command; I still need to wait some amount of
> >> time until hardware acknowledges the commands like reset/enable/disable.
> >> These are relatively faster operations happening in microseconds. That's
> >> why, I have mdelay there.
> >>
> >> I'll take a look at workqueues but it could turn out to be an overkill
> >> for few microseconds.
> >
> > Most devices are able to provide an interrupt for long-running commands.
> > Are you sure that yours is unable to do this? If so, is this a design
> > mistake or an implementation bug?
> 
> I think I was not clear on how long these command take. These command 
> are really fast and get acknowledged at status register in few 
> microseconds. That's why I choose polling.
> 
> I was waiting up to 10ms before and manually sleeping 1 milliseconds in 
> between each using mdelay. I followed your suggestion and got rid of the 
> mdelay. Then, I used polled read command which calls the usleep_range 
> function as you suggested.
> 
> Hardware supports error interrupts but this is a SW design philosophy 
> discussion. Why would you want to trigger an interrupt for few 
> microseconds delay that only happens during the first time init from probe?

If you get called in sleeping context and can use usleep_range() for
delaying, that is fine, but in effect that just means you generate another
interrupt from the timer that is not synchronized to your device, and
hide the complexity behind the usleep_range() function call.

My first choice would have been to use a struct completion to wait for
the next interrupt here, which has similar complexity on the source code
side, but never waits longer than necessary. If the hrtimer based method
works for you, there is no need to change that.

> >> I checked with the hardware designers. Hardware guarantees that by the
> >> time interrupt is observed, all data transactions in flight are
> >> delivered to their respective places and are visible to the CPU. I'll
> >> add a comment in the code about this.
> >
> > I'm curious about this. Does that mean the device is not meant for
> > high-performance transfers and just synchronizes the bus before
> > triggering the interrupt?
> 
> HIDMA meaning, as you probably guessed, is high performance DMA. We had 
> several name iterations in the company and this was the one that sticked.
> 
> I'm a SW person. I don't have the expertise to go deeper into HW design.
> I'm following the programming document. It says coherency and guaranteed 
> interrupt ordering. High performance can mean how fast you can move data 
> from one location to the other one vs. how fast you can queue up 
> multiple requests and get acks in response.
> 
> I followed a simple design here. HW can take multiple requests 
> simultaneously and give me an ack when it is finished with interrupt.
> 
> If there are requests in flight, other requests will get queued up in SW 
> and will not be serviced until the previous requests get acknowledged. 
> Then, as soon as HW stops processing; I queue a bunch of other requests 
> and kick start it. Current SW design does not allow simultaneous SW 
> queuing vs. HW processing. I can try this on the next iteration. This 
> implementation, IMO, is good enough now and has been working reliably 
> for a long time (since 2014).

Are you using message signaled interrupts then? Typically MSI guarantees
ordering against DMA, but level or edge triggered interrupts by definition
cannot (at least on PCI, but most other buses are the same way), because
the DMA master has no insight into when a DMA is actually complete.

If you use MSI, please add a comment to the readl_relaxed() that it
is safe because of that, otherwise the next person who tries to debug
a problem with your driver has to look into this.

> >>> In other words, when the hardware sends you data followed by an
> >>> interrupt to tell you the data is there, your interrupt handler
> >>> can tell the driver that is waiting for this data that the DMA
> >>> is complete while the data itself is still in flight, e.g. waiting
> >>> for an IOMMU to fetch page table entries.
> >>>
> >> There is HW guarantee for ordering.
> >>
> >> On demand paging for IOMMU is only supported 

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Arnd Bergmann]

On Monday 02 November 2015 13:49:35 Sinan Kaya wrote:
> On 11/2/2015 12:42 PM, Rob Herring wrote:
> > Except I was suggesting not using 1.0 or 1.1. There is one main
> > exception and that is Xilinx blocks, but they are releasing versions
> > of blocks to customers. If "1.0" is not a well defined number, then
> > don't use that. I'd be surprised if any SOC vendor had such well
> > defined process around versioning of their IP blocks such that they
> > are well documented and guaranteed such that every change will change
> > the version.
> 
> Here is one.
> 
> I have two versions of the same IP. The first version in one chip has 
> sw_version register that returns 1.0. The second version which has more 
> capabilities has 1.1 in it.
> 
> Is it OK to use?
> 
> compatible="qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"
> 
> for now and
> 
> compatible="qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt"
> 
> later for the second chip? 1.1 is backwards compatible with 1.0 BTW.

I think this is fine. As they are backwards compatible, I would even make the
latter one

compatible = "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt";

> Since the same IP goes into multiple chips, why would you list the chip 
> name here and submit patches multiple times for each single chip.
> 
> or to follow what Timur did, I can do this.
> 
> "qcom,qdf2xxx-hidma-mgmt-1.0"
> 
> qdf2xxx would become the chip family.

We really don't want wildcards in here, but want to use the most specific
name you have for it, so we can add quirks to the driver later if it
turns out that they are not fully compatible after all.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > +Required properties:
> > + - compatible: "ti,tsc2004"
> > + - interrupts: IRQ specifier
> > + - vio-supply : Regulator specifier
> 
> reg property?

Rob,

It appears that I missed this in the description.

Probably because I was following the lead of the ts2005 description.

How does this look:
- reg   : I2C address. 0x48 - 0x4b based on the voltage applied 
to
  the AD1 and AD0 inputs on the IC.

Do I have to spin the whole series to update this patch?

Everyone,

Are there any other concerns with this patch series?

Regards,

Michael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] sound: soc: Add Cygnus audio driver

[Simran Rai]

This patch adds Cygnus audio driver. It supports I2S, TDM and SPDIF
modes and uses three clocks derived from PLL.

This patchset has been tested on Cygnus wireless audio bcm958305K board.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
---
 sound/soc/bcm/Kconfig  |   18 +
 sound/soc/bcm/Makefile |5 +
 sound/soc/bcm/cygnus-pcm.c |  903 ++
 sound/soc/bcm/cygnus-ssp.c | 1532 
 sound/soc/bcm/cygnus-ssp.h |  129 
 5 files changed, 2587 insertions(+)
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..4015b35 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -7,3 +7,21 @@ config SND_BCM2835_SOC_I2S
  Say Y or M if you want to add support for codecs attached to
  the BCM2835 I2S interface. You will also need
  to select the audio interfaces to support below.
+
+config SND_SOC_CYGNUS
+   tristate "SoC platform audio for Broadcom Cygnus chips"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   help
+ Say Y if you want to add support for ASoC audio on Broadcom
+ Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
+
+config SND_SOC_CYGNUS_DIAG
+   bool "SoC platform audio for Broadcom Cygnus chips diagnostics"
+   depends on SND_SOC_CYGNUS
+   help
+ Say Y if you want to add diagnostics support in ASoC audio
+ on Broadcom Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
diff --git a/sound/soc/bcm/Makefile b/sound/soc/bcm/Makefile
index bc816b7..fc739d0 100644
--- a/sound/soc/bcm/Makefile
+++ b/sound/soc/bcm/Makefile
@@ -3,3 +3,8 @@ snd-soc-bcm2835-i2s-objs := bcm2835-i2s.o
 
 obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
 
+# CYGNUS Platform Support
+snd-soc-cygnus-objs := cygnus-pcm.o cygnus-ssp.o
+
+obj-$(CONFIG_SND_SOC_CYGNUS) += snd-soc-cygnus.o
+
diff --git a/sound/soc/bcm/cygnus-pcm.c b/sound/soc/bcm/cygnus-pcm.c
new file mode 100644
index 000..40aed25
--- /dev/null
+++ b/sound/soc/bcm/cygnus-pcm.c
@@ -0,0 +1,903 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+
+/* Register offset needed for ASoC PCM module */
+
+#define INTH_R5F_STATUS_OFFSET 0x040
+#define INTH_R5F_CLEAR_OFFSET  0x048
+#define INTH_R5F_MASK_SET_OFFSET   0x050
+#define INTH_R5F_MASK_CLEAR_OFFSET 0x054
+
+#define BF_REARM_FREE_MARK_OFFSET 0x344
+#define BF_REARM_FULL_MARK_OFFSET 0x348
+
+/* Ring Buffer Ctrl Regs --- Start */
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_RDADDR_REG_BASE */
+#define SRC_RBUF_0_RDADDR_OFFSET 0x500
+#define SRC_RBUF_1_RDADDR_OFFSET 0x518
+#define SRC_RBUF_2_RDADDR_OFFSET 0x530
+#define SRC_RBUF_3_RDADDR_OFFSET 0x548
+#define SRC_RBUF_4_RDADDR_OFFSET 0x560
+#define SRC_RBUF_5_RDADDR_OFFSET 0x578
+#define SRC_RBUF_6_RDADDR_OFFSET 0x590
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_WRADDR_REG_BASE */
+#define SRC_RBUF_0_WRADDR_OFFSET 0x504
+#define SRC_RBUF_1_WRADDR_OFFSET 0x51c
+#define SRC_RBUF_2_WRADDR_OFFSET 0x534
+#define SRC_RBUF_3_WRADDR_OFFSET 0x54c
+#define SRC_RBUF_4_WRADDR_OFFSET 0x564
+#define SRC_RBUF_5_WRADDR_OFFSET 0x57c
+#define SRC_RBUF_6_WRADDR_OFFSET 0x594
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_BASEADDR_REG_BASE */
+#define SRC_RBUF_0_BASEADDR_OFFSET 0x508
+#define SRC_RBUF_1_BASEADDR_OFFSET 0x520
+#define SRC_RBUF_2_BASEADDR_OFFSET 0x538
+#define SRC_RBUF_3_BASEADDR_OFFSET 0x550
+#define SRC_RBUF_4_BASEADDR_OFFSET 0x568
+#define SRC_RBUF_5_BASEADDR_OFFSET 0x580
+#define SRC_RBUF_6_BASEADDR_OFFSET 0x598
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_ENDADDR_REG_BASE */
+#define SRC_RBUF_0_ENDADDR_OFFSET 0x50c
+#define SRC_RBUF_1_ENDADDR_OFFSET 0x524
+#define SRC_RBUF_2_ENDADDR_OFFSET 0x53c
+#define SRC_RBUF_3_ENDADDR_OFFSET 0x554
+#define SRC_RBUF_4_ENDADDR_OFFSET 0x56c
+#define SRC_RBUF_5_ENDADDR_OFFSET 0x584
+#define SRC_RBUF_6_ENDADDR_OFFSET 0x59c
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_FREE_MARK_REG_BASE */
+#define 

Re: [PATCH] thermal: of: Introduce governor selection in dts

[Eduardo Valentin]

On Tue, Aug 11, 2015 at 10:07:31AM +0100, Sudeep Holla wrote:
> 
> 
> On 10/08/15 18:47, Javi Merino wrote:
> >On Mon, Aug 10, 2015 at 09:00:49AM +0100, Chung-Yih Wang (王崇懿) wrote:
> >>This patch was originally introduced when we made power_allocator the
> >>default governor where we had issues in binding a thermal zone w/o
> >>parameters to. Then we came out this facility for binding a specific
> >>governor to a thermal zone in dts instead of the default governor.
> >>Javi seems like this idea much.
> >
> >While I can understand why this is not suitable for devicetree, we
> >should have a way in the kernel to configure different governors for
> >different thermal zones defined in device tree.  Thermal zones defined
> >from platform code can choose the thermal governor when they are
> >registered.
> >
> >If this information can't go in device tree, where can we put it? As
> >an additional parameter to thermal_zone_of_sensor_register()?
> >
> 
> Why can't it be via sysfs allowing users to select their choice of
> governor ? (like cpuidle/freq or even devfreq I assume)
> 

Yes, sysfs configuration is the current recommended way. 

Although it is tempting to have it in device tree, its
design decisions are not meant for OS implementation/specifics.

BR,

> Regards,
> Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND v2 net-next] net: hisilicon: updates HNS config and documents

[Arnd Bergmann]

On Saturday 31 October 2015 02:18:19 Salil Mehta wrote:
> On 10/31/2015 1:40 AM, huangdaode wrote:
> > On 2015/10/30 22:20, Arnd Bergmann wrote:
> >> On Tuesday 27 October 2015 19:16:34 huangdaode wrote:
> >>>mdio@803c {
> >>>  #address-cells = <1>;
> >>>  #size-cells = <0>;
> >>> -   compatible = "hisilicon,mdio","hisilicon,hns-mdio";
> >>> +   compatible = "hisilicon,hns-mdio","hisilicon,mdio";
> >>>  reg = <0x0 0x803c 0x0 0x1>;
> >>>
> >> Does "hisilicon,mdio" actually have a specific meaning? Is that just 
> >> there
> >> for legacy reasons?
> >>
> >> Arnd
> >>
> >> .
> >>
> > hi Arnd,
> > "hisilicon,mdio" is  the gernerical configuation compatible  for the 
> > default hisilicon chip,
> > We use generic hisilicon since our MDIO/PHY is same across flavour of 
> > SoCs.
> >
> Hi Arnd,
> Yes, "hisilicon,mdio" exists for the legacy reasons to support older SoC 
> Hip04.

I see. In that case, that compatible string should probably be mentioned
only as 'optional' in the binding, and not used for devices other than
hip04.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] Add audio support for Broadcom Cygnus SoC

[Simran Rai]

Hi,

This patchset contains audio support for Broadcom's Cygnus SoC. It
contains DT bindings and core audio driver. The audio driver
supports both capture and playback of Audio PCM samples over I2S/TDM
interface and provides playback support over SPDIF interface.

This patchset is derived from a previously submitted patchset:
http://lkml.iu.edu/hypermail/linux/kernel/1503.3/05434.html

This patchset has been tested on Cygnus wireless audio bcm958305K board.
It is based on v4.3-rc5  and is available from github:

repo: https://github.com/Broadcom/cygnus-linux/tree/cygnus-sound-v2

Changes from v1:
  - Address code review comments. Fixed print format of type size_t and
pointer.

Simran Rai (2):
  dt-bindings: sound: Add DT bindings for Broadcom Cygnus audio
  VOIP-5227 Add Broadcom Cygnus audio driver.

 .../bindings/sound/brcm,cygnus-audio.txt   |   63 +
 sound/soc/bcm/Kconfig  |   18 +
 sound/soc/bcm/Makefile |5 +
 sound/soc/bcm/cygnus-pcm.c |  903 
 sound/soc/bcm/cygnus-ssp.c | 1532 
 sound/soc/bcm/cygnus-ssp.h |  129 ++
 6 files changed, 2650 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] rpi: add support to enable usb power domain

[Alexander Aring]

Hi,

On Thu, Oct 29, 2015 at 12:02:24PM -0700, Eric Anholt wrote:
> Alexander Aring  writes:
> 
> > This patch adds support for RPi several Power Domains and enable support
> > to enable the USB Power Domain when it's not enabled before.
> >
> > This patch based on Eric Anholt's patch to support Power Domains. He had
> > an issue about -EPROBE_DEFER inside the power domain subsystem, this
> > issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
> > if we fail to init or turn-on domain").
> >
> > It was tested with barebox and the following scripts before booting
...
> > Third:
> > The barebox regulator doesn't support right now to enable/disable
> > regulators at runtime but I want to bring this mainline in the next
> > days. So you can't check yourself if the above scripts working right
> > now. I describe it here to show you what exactly I tested.
> >
> > changes since Eric Anholts "power domain" patch:
> >  - add for me all known power domains of the RPi, it contains the domains
> >0 - 9.
> 
> Note: None of the power domain enums other than the ones I'd had in my
> patch are actually connected to anything in the firmware.  I don't think
> we should be adding them, given that.

Okay. Then it makes sense that I still accessing UART and SDHC when I
turn off the power.

In you patch you had SDHC, USB, DSI. Are you sure that SDHC power domain
has any effect, because I don't see any effect and can still access the
sd card.

I using "... firmware from 2015-10-28 17:06".

I would add the power-domains where we have currently an use-case for it
and this USB at the moment. Is this okay for you?

- Alex
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] ARM: dts: imx: Add Advantech BA-16 Qseven module

[Lucas Stach]

Am Donnerstag, den 29.10.2015, 19:16 -0400 schrieb Akshay Bhat:
> From: Justin Waters 
> 
> Add support for Advantech BA-16 module based on iMX6D processor
> 
> http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
> Signed-off-by: Akshay Bhat 
> ---
>  arch/arm/boot/dts/imx6q-ba16.dtsi | 559 
> ++
>  1 file changed, 559 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
> 
> diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi 
> b/arch/arm/boot/dts/imx6q-ba16.dtsi
> new file mode 100644
> index 000..3d47039
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
> @@ -0,0 +1,559 @@
> +/*
> + * Support for imx6 based Advantech DMS-BA16 Qseven module
> + *
> + * Copyright 2015 Timesys Corporation.
> + * Copyright 2015 GE Healthcare.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include "imx6q.dtsi"
> +#include 
> +
> +/ {
> + memory {
> + reg = <0x1000 0x4000>;
> + };
> +
> + clocks {
> + clk24m: clk24m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> +
> + reg_usb_otg_vbus: regulator@1 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + reg_usb_h1_vbus: regulator@2 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + reg_1p8v: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> + reg_3p3v: regulator@4 {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + lvds_ppen: regulator@5 {
> + compatible = "regulator-fixed";
> + regulator-name = "lvds_ppen";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + gpio = < 22 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> + };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + brightness-levels = <  0   1   2   3   4   5   6   7   8   9
> +   10  11  12  13  14  15  16  17  18  19
> +   20  21  22  23  24  25  26  27  28  29
> +   30  31  32  33  34  35  36  37  38  39
> +   40  41  42  43  44  45  46  47  48  49
> +   50  51  52  53  54  55  56  57  58  59
> +   60  61  62  63  64  65  66  67  68  69
> +   70  71  72  73  74  75  76  77  78  79
> +   80  81  82  83  84  85  86  87  88  89
> +   90  91  92  93  94  95  96  97  98  99
> +  100 101 102 103 104 105 106 107 108 109
> +  110 111 112 113 114 115 116 117 118 119
> +  120 121 122 123 124 125 126 127 128 129
> +  130 131 132 133 134 135 136 137 138 139
> +  140 141 142 143 144 145 146 147 148 149
> +  150 151 152 153 154 155 156 157 158 159
> +  160 161 162 163 164 165 166 167 168 169
> +  170 171 172 173 174 175 176 177 178 179
> +  180 181 182 183 184 185 186 187 188 189
> +  190 

[PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

[Alim Akhtar]

This patch add pmic (s2mps15) node of espresso board,
which includes addition of regulators and pmic-clk sub-nodes.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Alim Akhtar 
---
This patch should go in after driver side changes [1] lands.
[1]-> 
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg47736.html

 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349 +++
 1 file changed, 349 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 838a3626dac1..8ce04a0ec928 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -53,6 +53,355 @@
status = "okay";
 };
 
+_4 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <20>;
+   status = "okay";
+
+   s2mps15_pmic@66 {
+   compatible = "samsung,s2mps15-pmic";
+   reg = <0x66>;
+   interrupts = <2 0>;
+   interrupt-parent = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq>;
+   wakeup-source;
+
+   s2mps15_osc: clocks {
+   compatible = "samsung,s2mps13-clk";
+   #clock-cells = <1>;
+   clock-output-names = "s2mps13_ap", "s2mps13_cp",
+   "s2mps13_bt";
+   };
+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "vdd_ldo1";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <90>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo2_reg: LDO2 {
+   regulator-name = "vdd_ldo2";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <125>;
+   regulator-always-on;
+   };
+
+   ldo3_reg: LDO3 {
+   regulator-name = "vdd_ldo3";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo4_reg: LDO4 {
+   regulator-name = "vdd_ldo4";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <111>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo5_reg: LDO5 {
+   regulator-name = "vdd_ldo5";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo6_reg: LDO6 {
+   regulator-name = "vdd_ldo6";
+   regulator-min-microvolt = <225>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo7_reg: LDO7 {
+   regulator-name = "vdd_ldo7";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <115>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo8_reg: LDO8 {
+   regulator-name = "vdd_ldo8";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <100>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo9_reg: LDO9 {
+   regulator-name = "vdd_ldo9";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <100>;
+   

[PATCH 2/2] arm64: dts: exynos7: Enable HS200 mode operation

[Alim Akhtar]

This patch enables HS200 mode operation on exynos7 based
espresso board.
This also remove _broken-cd_ property as per mmc binding documentation
which say one of the properties between broken-cd and non-removable
should be used. And we already use _non-removable_ as emmc mounted
on board which is a non-removable device.

Signed-off-by: Alim Akhtar 
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 8ce04a0ec928..7f19b99fc85b 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -405,8 +405,8 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
cap-mmc-highspeed;
+   mmc-hs200-1_8v;
non-removable;
card-detect-delay = <200>;
clock-frequency = <8>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Mark Brown]

On Fri, Oct 30, 2015 at 05:41:43PM -0500, Andrew F. Davis wrote:

> +struct tps65086_regulator {
> + struct regulator_desc desc;
> + unsigned int decay_reg;
> + unsigned int decay_mask;

The decay_reg and decay_mask fields appear to be entirely write only,
why are they present?

> + ret = of_regulator_match(>dev, pdev->dev.of_node,
> +  tps65086_matches,
> +  ARRAY_SIZE(tps65086_matches));
> + if (ret < 0) {
> + dev_err(tps->dev, "Error parsing regulator init data\n");
> + return ret;
> + }

Please match regulators using the fields in the regulator_desc rather
than open coding.


signature.asc
Description: PGP signature

Re: [RFC] rpi: add support to enable usb power domain

[Alexander Aring]

On Wed, Oct 28, 2015 at 10:32:37PM -0600, Stephen Warren wrote:
> On 10/28/2015 02:40 PM, Alexander Aring wrote:
> > This patch adds support for RPi several Power Domains and enable support
> > to enable the USB Power Domain when it's not enabled before.
> > 
> > This patch based on Eric Anholt's patch to support Power Domains. He had
> > an issue about -EPROBE_DEFER inside the power domain subsystem, this
> > issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
> > if we fail to init or turn-on domain").
> 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
> >  
> > b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
> 
> >  firmware {
> > compatible = "raspberrypi,bcm2835-firmware";
> > mboxes = <>;
> > +   #power-domain-cells = <1>;
> > +};
> 
> I would have expected a separate DT node for the power domains driver
> that referenced the firmware node by phandle. I believe that's why the
> firmware node exports mailboxes to other drivers. If the firmware driver
> was going to implement all the features directly, it wouldn't need to
> act as a mailbox provider, since all the mailbox programming would be
> internal.
> 

ok.

> > diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> 
> > +#define RPI_POWER_DOMAIN(_domain, _name)   \
> > +   [_domain] = \
> > +   {   \
> 
> I'd expect { wrapped onto the previous line.
> 

ok.

> > +static int raspberrypi_firmware_set_power(struct rpi_firmware *fw,
> > + u32 domain, bool on)
> 
> > +   packet.on = on;
> > +   ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_POWER_STATE, ,
> > +   sizeof(packet));
> > +   if (!ret && !packet.on)
> > +   ret = -EINVAL;
> 
> The error is only reported for power off requests?
> 

grab it from old patch. I will fix that, I suppose it should something
like:

if (!ret && packet.on != on)
ret = -EINVAL;

to confirm if packet.on is set or unset afterwards. I don't know if this
is a valid error reporting mechanism from firmware.

I will drop such checking here.

> > +/* Asks the firmware to if power is on for a specific power domain. */
> > +static int raspberrypi_firmware_power_is_on(struct rpi_firmware *fw,
> > +   u32 domain)
> 
> > +   packet.domain = domain;
> > +   ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_POWER_STATE, ,
> > +   sizeof(packet));
> > +   if (ret < 0)
> > +   return ret;
> 
> Hmm. If rpi_firmware_property() returns <0 on error, I'm confused what
> the test I commented on above is intended to do.
> 

yes, I will fix it.

> > +/*
> > + * IMPORTANT: be sure this array has no entries which are not specified
> > + * between others by RPI_POWER_DOMAIN, otherwise mapping between
> > + * generic_pm_domain array doesn't work anymore.
> > + */
> 
> "has no entries which are not specified between others by
> RPI_POWER_DOMAIN" might be better phrased as "is contiguous" or
> "contains only contiguous entries".
> 

Okay, Eric Anholt told me to support the power domains which he had in
his patch only. I would add add the power domains only which has an
use-case -> "USB". 

> > @@ -208,15 +312,44 @@ static int rpi_firmware_probe(struct platform_device 
> > *pdev)
> 
> > +   for (i = 0; i < num_domains; i++) {
> > +   bool is_off;
> > +
> > +   rpi_power_domains[i].fw = fw;
> > +   power_domains[i] = _power_domains[i].base;
> > +
> > +   /* get the initial state */
> > +   ret = raspberrypi_firmware_power_is_on(fw, i);
> > +   if (ret < 0)
> > +   goto mbox;
> 
> The label name "mbox" doesn't give a clue that it's an error handler.
> "free_mbox" might be better.
> 

ok.

> > +mbox:
> > +   mbox_free_channel(fw->chan);
> > +   return ret;
> >  }
> 
> Does the pm_genpd_init() call for all the power domains need to be
> undone at all?

I would say yes. The function will call:

list_add(>gpd_list_node, _list);

And gpd_list is a _static_ list inside the generic power domain subsystem.
If probing fails we need to delete these entries from gpd_list again.

I searched the whole file about "gpd_list_node" and can't find a
list_del on it. :-( Seems such handling isn't supported, but I think
"normally" it should be cleanuped then.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html