(unknown),

(unknown),

[jobhunts02]

http://www.jagsxc.com/templates/beez/easyJob12.html

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

(unknown)

[Robert Schwebel]

<tomi.valkeinen@ti.com>, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: <Pine.LNX.4.64.1210042307300.3744@axis700.grange>
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

(unknown),

[Xiubo Li]

Hello,

This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver implementation. And the implementation is only compatible with device tree definition.

This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree.

Changed in v2:
- Use default settings for the generic dmaengine PCM driver.
- Separate receive and transmit setting in most functions, but some couldn't for the HW limitation.
- Drop some not reduntant code.
- Use devm_snd_soc_register_component() instead of snd_soc_register_component().
- Use devm_snd_soc_register_card() instead of devm_snd_soc_register_card().
- Adjust the code sentences sequence.
- Make the namespacing consistent.
- Rename CONFIG_SND_SOC_FSL_SGTL5000 to CONFIG_SND_SOC_FSL_SGTL5000_VF610.
- Drop some meaningless lines.
- Rename the binding document file.

Added in v1:
- Add SAI SoC Digital Audio Interface driver.
- Add Freescale SAI ALSA SoC Digital Audio Interface node for VF610.
- Enables SAI ALSA SoC DAI device for Vybrid VF610 TOWER board.
- Add device tree bindings for Freescale SAI.
- Revise the bugs about the sgt15000 codec.
- Add SGT15000 based audio machine driver.
- Enable SGT15000 codec based audio driver node for VF610.
- Add device tree bindings for Freescale VF610 sound.

(unknown)

[Dave & Angela Dawes]

This is Dave and Angela, My wife and I won the biggest Euro Millions, we
just commenced a Charity Donation by giving out to five (5) individuals;
we listed you as a recipient of our cash donation. get back to us for more
info and proof.

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

(unknown),

[Management]

This is an automatic message by the system to let you know that you have
to confirm your account information. An Attempt has been made to login
from a new computer. For the security of your account.

Your Email account will be frozen temporary after 48 hours in order to
protect it.

The account will continue to be frozen until it is confirmed.Once you have
updated your account records, your information will be confirmed and your
account will start to work as normal once again. The process does not take
more than 5 minutes To proceed to confirm your account information Click
on this link or copy and paste in your browser tab:
http://666-17-79187.webs.com/

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

(unknown),

[Jagan Teki]

-- 
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Loc Ho]

This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.

v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values

v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment

v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation

v1
* Initial version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  PHY: Add function set_speed to generic PHY framework
  Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
    binding documentation
  PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
  arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

 .../devicetree/bindings/ata/apm-xgene-phy.txt      |   89 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   31 +
 drivers/phy/Kconfig                                |    7 +
 drivers/phy/Makefile                               |    2 +
 drivers/phy/phy-core.c                             |   21 +
 drivers/phy/phy-xgene.c                            | 1854 ++++++++++++++++++++
 include/linux/phy/phy.h                            |    8 +
 7 files changed, 2012 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene-phy.txt
 create mode 100644 drivers/phy/phy-xgene.c

(unknown)

[klightspeed-aslSrjg9ejhWX4hkXwHRhw]

>From f3b6db2e9607c22d1a7e16de9c4872539f4d786c Mon Sep 17 00:00:00 2001
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org
Date: Sat, 11 Jan 2014 10:03:58 +1000
Subject: [PATCH] ARM: parameter initrd must override FDT initrd

The initrd_start and initrd_end as set by FDT was overriding
the phys_initrd_start and phys_initrd_size set by the initrd=
kernel parameter.  This patch will ignore the initrd_start
and initrd_end set earlier if phys_initrd_start and
phys_initrd_size (as set by the initrd= parameter) are set.

Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
---
 arch/arm/mm/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 1f7b19a..819c539 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -345,10 +345,11 @@ void __init arm_memblock_init(struct meminfo *mi,
 #endif
 #ifdef CONFIG_BLK_DEV_INITRD
 	/* FDT scan will populate initrd_start */
-	if (initrd_start) {
+	if (initrd_start && !phys_initrd_size) {
 		phys_initrd_start = __virt_to_phys(initrd_start);
 		phys_initrd_size = initrd_end - initrd_start;
 	}
+	initrd_start = initrd_end = 0;
 	if (phys_initrd_size &&
 	    !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
 		pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
-- 
1.8.3.2

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

(unknown),

[Lothar Waßmann]

This patchset adds support for inverting the PWM output in hardware by
setting the POUTC bit in the PWMCR register. This feature is
controlled via the standard DT flas for PWMs.

The first patch does a minor source cleanup without any functional
change.

(unknown),

[Lothar Waßmann]

This patchset adds support for the Ka-Ro electronics i.MX53 based
modules.
The first patch adds a new pingroup for NAND pads that is used by the
modules.

(unknown),

[Loc Ho]

This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.

v8
* Update binding documentation
* Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines
* Remove support for internal clock
* Remove support for external reference CMU
* Remove the need for external reference resource DTS entry and its related
  code

v7
* Add/Update PHY CMU/lane parameters and its default values
* Rename variable enable_manual_cal to preA3Chip
* Remove function phy_rd, phy_wr, and phy_wr_flush
* Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits,
  serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context
  instead void *
* Remove function serdes_toggle1to0
* Decrease the polling time from 10ms to 1ms on CMU calibration complete
  detection
* Move all SATA specify code in function xgene_phy_hw_initialize into
  function xgene_phy_hw_init_sata
* Add usleep_range after starting summer/latch calibrations
* Add usleep_range between receiver reset (function xgene_phy_reset_rxd)
* Save and restore PHY register 31 instead writing 0 in function
  xgene_phy_gen_avg_val
* Update function xgene_phy_sata_force_gen programming sequences
* Add support to reset the receiver lane in function xgene_phy_set_speed
  if speed is 0
* Update PHY parameters in DTS per controller
* Some minor code clean up

v6
* Move PHY document to Documentation/devicetree/binding/phy
* Remove _ADDR from all register defines
* Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk

v5
* Update DTS binding documentation
* Remove direct clock access and use clock interface instead
* Change override parameters to decimal instead hex values
* Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2,
  apm,tx-post-cursor to be unit of uV

v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values

v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment

v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation

v1
* Initial version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  PHY: Add function set_speed to generic PHY framework
  Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
    binding documentation
  PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
  arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

 .../devicetree/bindings/phy/apm-xgene-phy.txt      |   79 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   75 +
 drivers/phy/Kconfig                                |    7 +
 drivers/phy/Makefile                               |    2 +
 drivers/phy/phy-core.c                             |   21 +
 drivers/phy/phy-xgene.c                            | 1793 ++++++++++++++++++++
 include/linux/phy/phy.h                            |    8 +
 7 files changed, 1985 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
 create mode 100644 drivers/phy/phy-xgene.c

(unknown),

[Loc Ho]

This patch adds support for the APM X-Gene SoC SATA host controller. In
order for the host controller to work, the corresponding PHY driver
musts also be available.

v10:
 * Update binding documentation

v9:
 * Remove ACPI/EFI include files
 * Remove the IO flush support, interrupt routine, and DTS resources
 * Remove function xgene_rd, xgene_wr, and xgene_wr_flush
 * Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
   xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
 * Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
 * Clean up hardreset functions
 * Require v7 of the PHY driver

v8:
 * Remove _ADDR from defines
 * Remove define MSTAWAUX_COHERENT_BYPASS_SET and
   STARAUX_COHERENT_BYPASS_SET and use direct coding
 * Remove the un-necessary check for DTS boot with built in ACPI table
 * Switch to use dma_set_mask_and_coherent for setting DMA mask
 * Remove ACPI table matching code
 * Update clock-names for sata01clk, sata23clk, and sata45clk

v7:
 * Update the clock code by toggle the clock
 * Update the DTS clock mask values due to the clock spilt between host and
   v5 of the PHY drivers

v6:
 * Update binding documentation
 * Change select PHY_XGENE_SATA to PHY_XGENE
 * Add ULL to constants
 * Change indentation and comments
 * Clean up the probe functions a bit more
 * Remove xgene_ahci_remove function
 * Add the flush register to DTS
 * Remove the interrupt-parent from DTS

v5:
 * Sync up to v3 of the PHY driver
 * Remove MSLIM wrapper functions
 * Change the memory shutdown loop to use usleep_range
 * Use devm_ioremap_resource instead devm_ioremap
 * Remove suspend/resume functions as not needed

v4:
 * Remove the ID property in DT
 * Remove the temporary PHY direct function call and use PHY function
 * Change printk to pr_debug
 * Move the IOB flush addresses into the DT
 * Remove the parameters retrieval function as no longer needed
 * Remove the header file as no longer needed
 * Require v2 patch of the SATA PHY driver. Require slightly modification
   in the Kconfig as it is moved to folder driver/phy and use Kconfig
   PHY_XGENE_SATA instead SATA_XGENE_PHY.

v3:
 * Move out the SATA PHY to another driver
 * Remove the clock-cells entry from DTS
 * Remove debug wrapper
 * Remove delay functions wrapper
 * Clean up resource and IRQ query
 * Remove query clock name
 * Switch to use dma_set_mask/dma_coherent_mask
 * Remove un-necessary devm_kfree
 * Update GPL license header to v2
 * Spilt up function xgene_ahci_hardreset
 * Spilt up function xgene_ahci_probe
 * Remove all reference of CONFIG_ARCH_MSLIM
 * Clean up chip revision code

v2:
 * Clean up file sata_xgene.c with Lindent and etc
 * Clean up file sata_xgene_serdes.c with Lindent and etc
 * Add description to each patch

v1:
 * inital version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  ata: Export required functions by APM X-Gene SATA driver
  Documentation: Add documentation for APM X-Gene SoC SATA host
    controller DTS binding
  ata: Add APM X-Gene SoC SATA host controller driver
  arm64: Add APM X-Gene SoC SATA host controller DTS entries

 .../devicetree/bindings/ata/apm-xgene.txt          |   70 +++
 arch/arm64/boot/dts/apm-storm.dtsi                 |   75 +++
 drivers/ata/Kconfig                                |    8 +
 drivers/ata/Makefile                               |    1 +
 drivers/ata/ahci.h                                 |    9 +
 drivers/ata/libahci.c                              |   16 +-
 drivers/ata/sata_xgene.c                           |  630 ++++++++++++++++++++
 7 files changed, 803 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
 create mode 100644 drivers/ata/sata_xgene.c

(unknown),

[Davor Joja]

Hi,

I would like to ask for comments on these patches.

Their purpose is to show how I did binding for Xylon logiCVC IP core within
DRM driver.
First goal is to get comments on logiCVC binding so that I can use it in
community approved form in DRM and FB drivers and then send drivers to review.
Second goal is to get "xylon" prefix in vendor-prefixes.

Thanks,
Davor

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

(unknown),

[Eleazar Molina Molina]

Good day. I am Mark Reyes Guus, I not work with Abn Amro Bank as an auditor. I have a proposition to discuss with you. Should you be interested, Please e-mail back to me.

Private Email: markreyesguus@abnmrob.co.uk OR markguus.reyes01 @ yahoo.nl

Yours Sincerely,
Guus Mark Reyes.

________________________________

La información de este correo así como la contenida en los documentos que se adjuntan, pueden ser objeto de solicitudes de acceso a la información. Visítanos: http://www.ipn.mx

(unknown),

[Hans de Goede]

Hi all,

Here is v7 of my patchset for adding ahci-sunxi support. This is hopefully
the final final version of this set :)

Note I'm going on vacation for a week starting Monday, so if I'm not responding
that is why. Tejun if you feel some small cleanups are still necessary and
you don't want to wait for me to get back feel free to squash in any cleanups
you deem necessary.

This has been tested with Allwinner A10, Allwinner A20 and Freeware imx6x SoCs,
including suspend / resume. Note that the ahci_imx driver now also has imx53
sata support, it would be good if someone could test that with this series.


History:

v1, by Olliver Schinagl:
This was using the approach of having a platform device which probe method
creates a new child platform device which gets driven by ahci_platform.c,
as done by ahci_imx.c .

v2, by Hans de Goede:
Stand-alone platform driver based on Olliver's work

v3, by Hans de Goede:
patch-series, with 4 different parts
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
   regulator
b) New ahci-sunxi code only populating ahci_platform_data, passed to
   ahci_platform.c to of_device_id matching.
c) Refactor ahci-imx code to work the same as the new ahci-sunxi code, this
   is the reason why v3 is an RFC, I'm waiting for the wandboard I ordered to
   arrive so that I can actually test this.
d) dts bindings for the sunxi ahci parts

v4, by Hans de Goede:
patch-series, with 5 different parts:
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
   regulator
b) Turn parts of ahci_platform.c into a library for use by other drivers
c) New ahci-sunxi driver using the ahci_platform.c library functionality
d) Refactor ahci-imx code to work the same as the new ahci-sunxi code
e) dts bindings for the sunxi ahci parts

v5:
v4 + the following changes:
1) fsl,imx6q driver is now tested
2) fixed suspend / resume on fsl,imx6q
3) Modifed devicetree node naming to match dt spec
4) Reworked the busy waiting code in the sunxi-phy handling as suggested by
   Russell King

v6:
v5 rebased on top of 3.14-rc3 + the following changes
1) Added Roger Quadros' generic phy support series
2) Added a "ARM: sun4i: dt: Remove grouping + simple-bus for regulators" dts
   patch

v7:
v6 + the following changes:
1) Addressed all Tejun's review remarks:
  * Added function header comments to all exported ahci_platform functions
  * Added comments in some other places
  * Removed use of 2 empty lines to separate functions in some cases
  * Use devres to automatically call ahci_platform_put_resources on
    get_resource failure, probe failure and regular device remove
2) Dropped patches to move ahci_host_priv struct declaration to include/linux,
  this was a left-over from v3 and is no longer necessary
3) Updated Roger's "ata: ahci_platform: Manage SATA PHY" patch:
  * Update function header comments for the changes this makes
  * Drop the Kconfig PHY requires hack, my patch for the phy-core to always be
    built-in has been queued in Greg KH's tree, so this is no longer necessary.
4) Dropped Roger's "ata: ahci_platform: Add 'struct device' argument to ahci_platform_put_resources()"
  patch, ahci_platform_put_resources already has a device argument as result
  of it being changed into a devres release function

Tejun, can you please add patches 1-12 to your ata tree for 3.15 ?

Maxime, can you please add patch 13-15 to your dts tree for 3.15 ?

Thanks & Regards,

Hans

(unknown),

[Christian Organization]

Good day,

We are Christian organization, we give out loan to those that have given
there lives to Christ, contact us via email marieloanlenders-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Regard

Mrs Marie



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

(unknown),

[Loc Ho]

This patch adds support for the APM X-Gene SoC EDAC driver.

v2:
* Add EDAC entry in MAINTAINERS for APM EDAC driver
* Remove the MC scrub patch
* Remove the word 'Caches' from Kconfig
* Change all MASK defines to use BIT(x)
* Update comment or remove them
* Wrap error injection code around CONFIG_EDAC_DEBUG
* Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl
* Change all function XXX_hw_init to XXX_hw_ctl
* Fix typo 'activie'
* Move calling function edac_mc_alloc after resource retrieval
* Check for NULL on platform_get_resource return if reference directly
* Add documentation for struct xgene_edac_pmd_ctx
* Move L1 and L2 check out of function xgene_edac_pmd_check to its own
  functions
* Use for loop for configure each CPU of an PMD
* Replace /2 by >> 1
* Remove unnecessary comment on edac_device_add_device failure
* Make mem_err_ip static const
* Unwind EDAC register correctly if failed
---
Loc Ho (4):
  MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
  Documentation: Add documentation for the APM X-Gene SoC EDAC DTS
    binding
  edac: Add APM X-Gene SoC EDAC driver
  arm64: Add APM X-Gene SoC EDAC DTS entries

 .../devicetree/bindings/edac/apm-xgene-edac.txt    |   70 +
 MAINTAINERS                                        |    8 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   89 +
 drivers/edac/Kconfig                               |    9 +-
 drivers/edac/Makefile                              |    3 +
 drivers/edac/xgene_edac.c                          | 1993 ++++++++++++++++++++
 6 files changed, 2171 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
 create mode 100644 drivers/edac/xgene_edac.c

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

(unknown),

[M.K-YIN]

--
I have a portfolio project for you.

Regards,
M.K-YIN
--

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

(unknown),

[Jingchang Lu]

This series contain the support for Freescale LS1021A CPU and LS1021A-QDS
and LS1021A-TWR board.

The LS1021A SoC combines two ARM Cortex-A7 cores that have been optimized
for high reliability and pack the highest level of integration available
for sub-3W embedded communications processors and with a comprehensive
enablement model focused on ease of programmability.

The LS1021A SoC shares IPs with i.MX family, Vybrid family and Freescale
PowerPC platform. 

For the detail information about LS1021A SoC, please refer to the RM doc.

---
changes in v4:
add "syscon" compatible to device tree scfg and dcfg node, and 
remove uncompleted dcsr related node.
remove mxc_restart reference in DT_MACHINE_START.
remove dma_zone_size defination in DT_MACHINE_START.

changes in v3:
rewrite scfg and dcfg binding doc description.
remove sai related node leaving to the driver support.

changes in v2:
remove unused nodes.
wakeup the secondary core by IPI call to u-boot standby procedure. 
add dt-bindings for LS1021A SoC and platform gerenal configuration nodes.

----------------------------------------------------------------
Jingchang Lu (6):
	ARM: dts: Add SoC level device tree support for LS1021A
	ARM: dts: Add initial LS1021A QDS board dts support
	ARM: dts: Add initial LS1021A TWR board dts support
	dt-bindings: arm: add Freescale LS1021A SoC device tree binding
	ARM: imx: Add initial support for Freescale LS1021A
	ARM: imx: Add Freescale LS1021A SMP support

 Documentation/devicetree/bindings/arm/fsl.txt |  38 ++++
 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/ls1021a-qds.dts             | 285 ++++++++++++++++++++++++++
 arch/arm/boot/dts/ls1021a-twr.dts             | 117 +++++++++++
 arch/arm/boot/dts/ls1021a.dtsi                | 539 ++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/Kconfig                     |  14 ++
 arch/arm/mach-imx/Makefile                    |   4 +-
 arch/arm/mach-imx/common.h                    |   1 +
 arch/arm/mach-imx/mach-ls1021a.c              |  22 +++
 arch/arm/mach-imx/platsmp.c                   |  32 +++
 10 files changed, 1053 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts
 create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts
 create mode 100644 arch/arm/boot/dts/ls1021a.dtsi
 create mode 100644 arch/arm/mach-imx/mach-ls1021a.c

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

(unknown),

[Shengchao Guo]

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

(unknown),

[Suman Tripathi]

commit 72f79f9e35bd3f78ee8853f2fcacaa197d23ebac upstream.
Subject: [PATCH 3.16 350/357] ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver.

This patch removes the NCQ support from the APM X-Gene SoC AHCI
Host Controller driver as it doesn't support it.

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
[bwh: Backported to 3.16: host flags are passed to ahci_platform_init_host()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Suman Tripathi <stripathi@apm.com>

---
 drivers/ata/ahci_xgene.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -337,7 +337,7 @@ static struct ata_port_operations xgene_
 };
 
 static const struct ata_port_info xgene_ahci_port_info = {
-	.flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
+	.flags = AHCI_FLAG_COMMON,
 	.pio_mask = ATA_PIO4,
 	.udma_mask = ATA_UDMA6,
 	.port_ops = &xgene_ahci_ops,
@@ -484,7 +484,7 @@ static int xgene_ahci_probe(struct platf
 		goto disable_resources;
 	}
 
-	hflags = AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ;
+	hflags = AHCI_HFLAG_NO_PMP | AHCI_HFLAG_NO_NCQ;
 
 	rc = ahci_platform_init_host(pdev, hpriv, &xgene_ahci_port_info,
 				     hflags, 0, 0);

(unknown),

[Omar Hashim]

--
I have a lucrative business proposal of 
mutual interest to share with you, 
contact me if you are interested.
--

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

(unknown)

[MRS GRACE MANDA]

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









This is Mrs Grace Manda (  Please I need your Help is Urgent).






This is Mrs Grace Manda (  Please I need your Help is Urgent). 

[-- Attachment #2: Mrs Grace Manda.rtf --]
[-- Type: application/rtf, Size: 35796 bytes --]

(unknown),

[Lee Jones]

Subject: [PATCH v2 0/4] clk: st: New clock domain

v1 => v2:
  - Turned the ST specific driver into a generic one 

Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die.  The only way to recover from this failure is to
restart.
 
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.

Lee Jones (4):
  ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
  ARM: sti: stih407-family: Provide Clock Domain information
  clk: Provide an always-on clock domain framework
  clk: dt: Introduce always-on clock domain documentation

 .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++
 arch/arm/boot/dts/stih407-family.dtsi              | 13 +++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clkdomain.c                            | 63 ++++++++++++++++++++++
 include/dt-bindings/clock/stih407-clks.h           |  4 ++
 5 files changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
 create mode 100644 drivers/clk/clkdomain.c

-- 
1.9.1

[PATCH v2 1/4] ARM: sti: stih407-family: Supply defines for CLOCKGEN A0

[Lee Jones]

There are 2 LMI clocks generated by CLOCKGEN A0.  We wish to control
them individually and need to use these indexes to do so.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 include/dt-bindings/clock/stih407-clks.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/dt-bindings/clock/stih407-clks.h b/include/dt-bindings/clock/stih407-clks.h
index 7af2b71..082edd9 100644
--- a/include/dt-bindings/clock/stih407-clks.h
+++ b/include/dt-bindings/clock/stih407-clks.h
@@ -5,6 +5,10 @@
 #ifndef _DT_BINDINGS_CLK_STIH407
 #define _DT_BINDINGS_CLK_STIH407
 
+/* CLOCKGEN A0 */
+#define CLK_IC_LMI0		0
+#define CLK_IC_LMI1		1
+
 /* CLOCKGEN C0 */
 #define CLK_ICN_GPU		0
 #define CLK_FDMA		1
-- 
1.9.1

[PATCH v2 2/4] ARM: sti: stih407-family: Provide Clock Domain information

[Lee Jones]

Certain clocks should not be turned of by clk_disable_unused.  Until
now we have been using the kernel command-line of the same name to
prevent common clk from turning off all clocks without a reference,
as this would ensure hardware lockup.  This patch lists each clock
which need to stay on to prevent the aforementioned issue from
arising.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 3e31d32..49af509 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -34,6 +34,19 @@
 		reg = <0x08761000 0x1000>, <0x08760100 0x100>;
 	};
 
+	clk-domain {
+		compatible = "always-on-clk-domain";
+		clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_COMPO_DVP>,
+			 <&clk_s_c0_flexgen CLK_MMC_1>,
+			 <&clk_s_c0_flexgen CLK_ICN_SBC>,
+			 <&clk_s_c0_flexgen CLK_ICN_LMI>,
+			 <&clk_s_c0_flexgen CLK_ICN_CPU>,
+			 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+			 <&clk_s_a0_flexgen CLK_IC_LMI0>,
+			 <&clk_m_a9>;
+	};
+
 	scu@08760000 {
 		compatible = "arm,cortex-a9-scu";
 		reg = <0x08760000 0x1000>;
-- 
1.9.1

[PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Lee Jones]

Much h/w contain clocks which if turned off would prove fatal.  The
only way to recover is to restart the board(s).  This driver takes
references to clocks which are required to be always-on in order to
prevent the common clk framework from trying to turn them off during
the clk_disabled_unused() procedure.

Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/clk/Makefile    |  1 +
 drivers/clk/clkdomain.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)
 create mode 100644 drivers/clk/clkdomain.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d5fba5b..d9e2718 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_HAVE_CLK)		+= clk-devres.o
 obj-$(CONFIG_CLKDEV_LOOKUP)	+= clkdev.o
 obj-$(CONFIG_COMMON_CLK)	+= clk.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-divider.o
+obj-$(CONFIG_COMMON_CLK)	+= clkdomain.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-fixed-factor.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-fixed-rate.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-gate.o
diff --git a/drivers/clk/clkdomain.c b/drivers/clk/clkdomain.c
new file mode 100644
index 0000000..8c83f99
--- /dev/null
+++ b/drivers/clk/clkdomain.c
@@ -0,0 +1,63 @@
+/*
+ * ST Clock Domain
+ *
+ * Copyright (C) 2015 STMicroelectronics – All Rights Reserved
+ *
+ * Author: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk-private.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+static void ao_clock_domain_hog_clock(struct platform_device *pdev, int index)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct clk *clk;
+	int ret;
+
+	clk = of_clk_get(np, index);
+	if (IS_ERR(clk)) {
+		dev_warn(&pdev->dev, "Failed get clock %s[%d]: %li\n",
+			 np->full_name, index, PTR_ERR(clk));
+		return;
+	}
+
+	ret = clk_prepare_enable(clk);
+	if (ret)
+		dev_warn(&pdev->dev, "Failed to enable clock: %s\n", clk->name);
+}
+
+static int ao_clock_domain_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int nclks, i;
+
+	nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+
+	for (i = 0; i < nclks; i++)
+		ao_clock_domain_hog_clock(pdev, i);
+
+	return 0;
+}
+
+static const struct of_device_id ao_clock_domain_match[] = {
+	{ .compatible = "always-on-clk-domain" },
+	{ },
+};
+
+static struct platform_driver ao_clock_domain_driver = {
+	.probe = ao_clock_domain_probe,
+	.driver = {
+		.name = "always-on-clk-domain",
+		.of_match_table = ao_clock_domain_match,
+	},
+};
+module_platform_driver(ao_clock_domain_driver);
-- 
1.9.1

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

[PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt

diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
new file mode 100644
index 0000000..b86772f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
@@ -0,0 +1,35 @@
+Always-on Clock Domain
+
+Some hardware is contains bunches of clocks which must never be
+turned off.  If drivers a) fail to obtain a reference to any of
+these or b) give up a previously obtained reference during suspend,
+the common clk framework will attempt to disable them and the
+hardware can fail irrecoverably.  Usually, the only way to recover
+from these failures is to restart.
+
+To avoid either of these two scenarios from catastrophically
+disabling an otherwise perfectly healthy running system, we have
+implemented a clock domain where clocks are consumed and references
+are taken, thus preventing them from being shut down by the
+framework.
+
+We use the generic clock bindings found in:
+  Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Must be "always-on-clk-domain"
+
+Example:
+
+clk-domain {
+	compatible = "always-on-clk-domain";
+	clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+		 <&clk_s_c0_flexgen CLK_COMPO_DVP>,
+		 <&clk_s_c0_flexgen CLK_MMC_1>,
+		 <&clk_s_c0_flexgen CLK_ICN_SBC>,
+		 <&clk_s_c0_flexgen CLK_ICN_LMI>,
+		 <&clk_s_c0_flexgen CLK_ICN_CPU>,
+		 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+		 <&clk_s_a0_flexgen CLK_IC_LMI0>,
+		 <&clk_m_a9>;
+};
-- 
1.9.1

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Rob Herring]

On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
> new file mode 100644
> index 0000000..b86772f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
> @@ -0,0 +1,35 @@
> +Always-on Clock Domain
> +
> +Some hardware is contains bunches of clocks which must never be
> +turned off.  If drivers a) fail to obtain a reference to any of
> +these or b) give up a previously obtained reference during suspend,
> +the common clk framework will attempt to disable them and the
> +hardware can fail irrecoverably.  Usually, the only way to recover
> +from these failures is to restart.

How is (b) not a bug?

While I think we need something here, I worry that this will be abused
to be a list of clocks you have not gotten around to managing. We
cannot be changing the DT every time the kernel starts managing a
clock. I think this should operate more as always on until claimed.
But then you get into drivers having to be aware that the clock
started enabled.

Also, I feel like we are using DT to work around kernel policy (of
turning off clocks). If the policy was to leave on clocks, then we
would be trying to put a list of clocks to disable in DT.

Rob

> +
> +To avoid either of these two scenarios from catastrophically
> +disabling an otherwise perfectly healthy running system, we have
> +implemented a clock domain where clocks are consumed and references
> +are taken, thus preventing them from being shut down by the
> +framework.
> +
> +We use the generic clock bindings found in:
> +  Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : Must be "always-on-clk-domain"
> +
> +Example:
> +
> +clk-domain {
> +       compatible = "always-on-clk-domain";
> +       clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +                <&clk_s_c0_flexgen CLK_COMPO_DVP>,
> +                <&clk_s_c0_flexgen CLK_MMC_1>,
> +                <&clk_s_c0_flexgen CLK_ICN_SBC>,
> +                <&clk_s_c0_flexgen CLK_ICN_LMI>,
> +                <&clk_s_c0_flexgen CLK_ICN_CPU>,
> +                <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +                <&clk_s_a0_flexgen CLK_IC_LMI0>,
> +                <&clk_m_a9>;
> +};
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Wed, 18 Feb 2015, Rob Herring wrote:

> On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
> > new file mode 100644
> > index 0000000..b86772f5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
> > @@ -0,0 +1,35 @@
> > +Always-on Clock Domain
> > +
> > +Some hardware is contains bunches of clocks which must never be
> > +turned off.  If drivers a) fail to obtain a reference to any of
> > +these or b) give up a previously obtained reference during suspend,
> > +the common clk framework will attempt to disable them and the
> > +hardware can fail irrecoverably.  Usually, the only way to recover
> > +from these failures is to restart.
> 
> How is (b) not a bug?

Clocks are normally disabled during suspend.  When clocks are disabled
they give up their reference.  If references reach 0, the clock is
gated.  If one of these clocks is gated, the system will never come
out of suspend.

How is it a bug?

> While I think we need something here, I worry that this will be abused
> to be a list of clocks you have not gotten around to managing. We

You can say that about any framework.  It's our responsibility to ask
the right questions and to disallow it from being abused.  The clocks
I use in the (real-world) example in this set are _really_ always-on.
If any of them are turned off the system will cease to perform in any
meaningful way.

> cannot be changing the DT every time the kernel starts managing a
> clock. I think this should operate more as always on until claimed.

The point of this is that even when these clocks are claimed, there is
an issue that when unclaimed (i.e. during suspend) the clk framework
will attempt to gate them, and when they do *boom*.

> But then you get into drivers having to be aware that the clock
> started enabled.

This has nothing to do with the initial state of the clock.  It's
whether the clock is integral (i.e. is part of a vital interconnect)
that's important.  For instance, ST's bootloader turns on lots of
clocks which can be safely gated if unused.  The clocks we're
registering with this always-on framework cannot.

> Also, I feel like we are using DT to work around kernel policy (of
> turning off clocks). If the policy was to leave on clocks, then we
> would be trying to put a list of clocks to disable in DT.

I'm not sure I understand your point.  The current policy is correct
if it's power that you care about, which is invariably the point of
disabling clocks in the first place, right?  Also, this has nothing to
do with DT per say.  It's just another framework driver.

> > +To avoid either of these two scenarios from catastrophically
> > +disabling an otherwise perfectly healthy running system, we have
> > +implemented a clock domain where clocks are consumed and references
> > +are taken, thus preventing them from being shut down by the
> > +framework.
> > +
> > +We use the generic clock bindings found in:
> > +  Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Required properties:
> > +- compatible : Must be "always-on-clk-domain"
> > +
> > +Example:
> > +
> > +clk-domain {
> > +       compatible = "always-on-clk-domain";
> > +       clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> > +                <&clk_s_c0_flexgen CLK_COMPO_DVP>,
> > +                <&clk_s_c0_flexgen CLK_MMC_1>,
> > +                <&clk_s_c0_flexgen CLK_ICN_SBC>,
> > +                <&clk_s_c0_flexgen CLK_ICN_LMI>,
> > +                <&clk_s_c0_flexgen CLK_ICN_CPU>,
> > +                <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> > +                <&clk_s_a0_flexgen CLK_IC_LMI0>,
> > +                <&clk_m_a9>;
> > +};
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Rob Herring]

On Wed, Feb 18, 2015 at 11:12 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 18 Feb 2015, Rob Herring wrote:
>
>> On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> > ---
>> >  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
>> >  1 file changed, 35 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
>> > new file mode 100644
>> > index 0000000..b86772f5
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
>> > @@ -0,0 +1,35 @@
>> > +Always-on Clock Domain
>> > +
>> > +Some hardware is contains bunches of clocks which must never be
>> > +turned off.  If drivers a) fail to obtain a reference to any of
>> > +these or b) give up a previously obtained reference during suspend,
>> > +the common clk framework will attempt to disable them and the
>> > +hardware can fail irrecoverably.  Usually, the only way to recover
>> > +from these failures is to restart.
>>
>> How is (b) not a bug?
>
> Clocks are normally disabled during suspend.  When clocks are disabled
> they give up their reference.  If references reach 0, the clock is
> gated.  If one of these clocks is gated, the system will never come
> out of suspend.
>
> How is it a bug?

It a clock needs to be enabled during suspend, then the driver using
it should not disable it. Anyway, suspend is a bit orthogonal to this
issue.

>> While I think we need something here, I worry that this will be abused
>> to be a list of clocks you have not gotten around to managing. We
>
> You can say that about any framework.  It's our responsibility to ask
> the right questions and to disallow it from being abused.  The clocks
> I use in the (real-world) example in this set are _really_ always-on.
> If any of them are turned off the system will cease to perform in any
> meaningful way.

You cannot tell here up front whether clocks are really always-on. A
reviewer is not going to know, and the submitter may not even have all
the documentation and know the answer. Getting it wrong here means you
have to change the dtb to fix it. Granted, it doesn't really break
things in this case.

>> cannot be changing the DT every time the kernel starts managing a
>> clock. I think this should operate more as always on until claimed.
>
> The point of this is that even when these clocks are claimed, there is
> an issue that when unclaimed (i.e. during suspend) the clk framework
> will attempt to gate them, and when they do *boom*.
>
>> But then you get into drivers having to be aware that the clock
>> started enabled.
>
> This has nothing to do with the initial state of the clock.  It's
> whether the clock is integral (i.e. is part of a vital interconnect)
> that's important.  For instance, ST's bootloader turns on lots of
> clocks which can be safely gated if unused.  The clocks we're
> registering with this always-on framework cannot.

It does because you have to assume either the initial state is wrong
and you need to disable it, or that the initial state is correct and
you need to leave the clock enabled.

There are also other usecases such as simplefb where you want to leave
clocks on until the real fb driver takes over. Consoles have a similar
issue.

Perhaps you need to model your buses more completely? Does
simple-pm-bus help you?

>> Also, I feel like we are using DT to work around kernel policy (of
>> turning off clocks). If the policy was to leave on clocks, then we
>> would be trying to put a list of clocks to disable in DT.
>
> I'm not sure I understand your point.  The current policy is correct
> if it's power that you care about, which is invariably the point of
> disabling clocks in the first place, right?  Also, this has nothing to
> do with DT per say.  It's just another framework driver.

It does have something to do with DT because you are designing a
binding around what the kernel does. Should the kernel assume it can
disable clocks safely? Another OS may do the opposite and assume it
cannot turn-off unused clocks. Then you would have a list of clocks
safe to disable in DT.

This is also completely solvable within the framework driver by
claiming those clocks in the clock controller driver.

Rob

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Wed, 18 Feb 2015, Rob Herring wrote:

> On Wed, Feb 18, 2015 at 11:12 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 18 Feb 2015, Rob Herring wrote:
> >
> >> On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >> > ---
> >> >  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
> >> >  1 file changed, 35 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
> >> > new file mode 100644
> >> > index 0000000..b86772f5
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
> >> > @@ -0,0 +1,35 @@
> >> > +Always-on Clock Domain
> >> > +
> >> > +Some hardware is contains bunches of clocks which must never be
> >> > +turned off.  If drivers a) fail to obtain a reference to any of
> >> > +these or b) give up a previously obtained reference during suspend,
> >> > +the common clk framework will attempt to disable them and the
> >> > +hardware can fail irrecoverably.  Usually, the only way to recover
> >> > +from these failures is to restart.
> >>
> >> How is (b) not a bug?
> >
> > Clocks are normally disabled during suspend.  When clocks are disabled
> > they give up their reference.  If references reach 0, the clock is
> > gated.  If one of these clocks is gated, the system will never come
> > out of suspend.
> >
> > How is it a bug?
> 
> It a clock needs to be enabled during suspend, then the driver using
> it should not disable it. Anyway, suspend is a bit orthogonal to this
> issue.

IMO, it's not the driver's responsibility to know which clock they are
using and whether it's a critical clock or not.

> >> While I think we need something here, I worry that this will be abused
> >> to be a list of clocks you have not gotten around to managing. We
> >
> > You can say that about any framework.  It's our responsibility to ask
> > the right questions and to disallow it from being abused.  The clocks
> > I use in the (real-world) example in this set are _really_ always-on.
> > If any of them are turned off the system will cease to perform in any
> > meaningful way.
> 
> You cannot tell here up front whether clocks are really always-on. A
> reviewer is not going to know, and the submitter may not even have all
> the documentation and know the answer. Getting it wrong here means you
> have to change the dtb to fix it. Granted, it doesn't really break
> things in this case.

We should make it clear in the documentation that this framework
should only be used if the clock is a critical "if it's turned off it
will cripple the system" one.

> >> cannot be changing the DT every time the kernel starts managing a
> >> clock. I think this should operate more as always on until claimed.
> >
> > The point of this is that even when these clocks are claimed, there is
> > an issue that when unclaimed (i.e. during suspend) the clk framework
> > will attempt to gate them, and when they do *boom*.
> >
> >> But then you get into drivers having to be aware that the clock
> >> started enabled.
> >
> > This has nothing to do with the initial state of the clock.  It's
> > whether the clock is integral (i.e. is part of a vital interconnect)
> > that's important.  For instance, ST's bootloader turns on lots of
> > clocks which can be safely gated if unused.  The clocks we're
> > registering with this always-on framework cannot.
> 
> It does because you have to assume either the initial state is wrong
> and you need to disable it, or that the initial state is correct and
> you need to leave the clock enabled.

I think the kernel's policy is a good one i.e. wait until all devices
are probed and have had the opportunity to take the clocks they need,
at which point we can usually safely gate the remainder.  These types
of clocks are the exception however; hence the need for this driver.
There are other vendors which have similar issues with their h/w.
These are currently using bespoke versions of this implementation, but
IMO a generic solution would be better.

> There are also other usecases such as simplefb where you want to leave
> clocks on until the real fb driver takes over. Consoles have a similar
> issue.

Why wouldn't these devices have taken references by the time
clk_disable_unused() is called?

> Perhaps you need to model your buses more completely?

Would you mind explaining this a little more please?

> Does simple-pm-bus help you?

I have no idea what this is, and I'm struggling to grep for it too?

> >> Also, I feel like we are using DT to work around kernel policy (of
> >> turning off clocks). If the policy was to leave on clocks, then we
> >> would be trying to put a list of clocks to disable in DT.
> >
> > I'm not sure I understand your point.  The current policy is correct
> > if it's power that you care about, which is invariably the point of
> > disabling clocks in the first place, right?  Also, this has nothing to
> > do with DT per say.  It's just another framework driver.
> 
> It does have something to do with DT because you are designing a
> binding around what the kernel does. Should the kernel assume it can
> disable clocks safely?

I guess it depends on what you're trying to achieve.  Personally I
think the kernel's policy is a good one, especually with regards to
power saving.  What are you suggesting?  A new policy?

> Another OS may do the opposite and assume it
> cannot turn-off unused clocks. Then you would have a list of clocks
> safe to disable in DT.

Sounds bananas.  What's good about that kind of policy?  It wouldn't
matter anyway, both of these implementations can live harmoniously in
the same tree.

> This is also completely solvable within the framework driver by
> claiming those clocks in the clock controller driver.

This conversation has now gone full circle.  This was an earlier
suggestion, but it was considered hacky, and I'm inclined to agree.
An always-on power domain was deemed to be a much more elegant
solution.

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Rob Herring]

On Wed, Feb 18, 2015 at 3:54 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 18 Feb 2015, Rob Herring wrote:
>
>> On Wed, Feb 18, 2015 at 11:12 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Wed, 18 Feb 2015, Rob Herring wrote:
>> >
>> >> On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> >> > ---
>> >> >  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
>> >> >  1 file changed, 35 insertions(+)
>> >> >  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
>> >> > new file mode 100644
>> >> > index 0000000..b86772f5
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
>> >> > @@ -0,0 +1,35 @@
>> >> > +Always-on Clock Domain
>> >> > +
>> >> > +Some hardware is contains bunches of clocks which must never be
>> >> > +turned off.  If drivers a) fail to obtain a reference to any of
>> >> > +these or b) give up a previously obtained reference during suspend,
>> >> > +the common clk framework will attempt to disable them and the
>> >> > +hardware can fail irrecoverably.  Usually, the only way to recover
>> >> > +from these failures is to restart.
>> >>
>> >> How is (b) not a bug?
>> >
>> > Clocks are normally disabled during suspend.  When clocks are disabled
>> > they give up their reference.  If references reach 0, the clock is
>> > gated.  If one of these clocks is gated, the system will never come
>> > out of suspend.
>> >
>> > How is it a bug?
>>
>> It a clock needs to be enabled during suspend, then the driver using
>> it should not disable it. Anyway, suspend is a bit orthogonal to this
>> issue.
>
> IMO, it's not the driver's responsibility to know which clock they are
> using and whether it's a critical clock or not.

Certainly drivers should not know about clocks outside of their h/w
block, but they absolutely should know if a clock is needed for
wake-up.

>> >> While I think we need something here, I worry that this will be abused
>> >> to be a list of clocks you have not gotten around to managing. We
>> >
>> > You can say that about any framework.  It's our responsibility to ask
>> > the right questions and to disallow it from being abused.  The clocks
>> > I use in the (real-world) example in this set are _really_ always-on.
>> > If any of them are turned off the system will cease to perform in any
>> > meaningful way.
>>
>> You cannot tell here up front whether clocks are really always-on. A
>> reviewer is not going to know, and the submitter may not even have all
>> the documentation and know the answer. Getting it wrong here means you
>> have to change the dtb to fix it. Granted, it doesn't really break
>> things in this case.
>
> We should make it clear in the documentation that this framework
> should only be used if the clock is a critical "if it's turned off it
> will cripple the system" one.
>
>> >> cannot be changing the DT every time the kernel starts managing a
>> >> clock. I think this should operate more as always on until claimed.
>> >
>> > The point of this is that even when these clocks are claimed, there is
>> > an issue that when unclaimed (i.e. during suspend) the clk framework
>> > will attempt to gate them, and when they do *boom*.
>> >
>> >> But then you get into drivers having to be aware that the clock
>> >> started enabled.
>> >
>> > This has nothing to do with the initial state of the clock.  It's
>> > whether the clock is integral (i.e. is part of a vital interconnect)
>> > that's important.  For instance, ST's bootloader turns on lots of
>> > clocks which can be safely gated if unused.  The clocks we're
>> > registering with this always-on framework cannot.
>>
>> It does because you have to assume either the initial state is wrong
>> and you need to disable it, or that the initial state is correct and
>> you need to leave the clock enabled.
>
> I think the kernel's policy is a good one i.e. wait until all devices
> are probed and have had the opportunity to take the clocks they need,
> at which point we can usually safely gate the remainder.  These types
> of clocks are the exception however; hence the need for this driver.
> There are other vendors which have similar issues with their h/w.
> These are currently using bespoke versions of this implementation, but
> IMO a generic solution would be better.
>
>> There are also other usecases such as simplefb where you want to leave
>> clocks on until the real fb driver takes over. Consoles have a similar
>> issue.
>
> Why wouldn't these devices have taken references by the time
> clk_disable_unused() is called?

Not if the drivers are modules.

>> Perhaps you need to model your buses more completely?
>
> Would you mind explaining this a little more please?
>
>> Does simple-pm-bus help you?
>
> I have no idea what this is, and I'm struggling to grep for it too?

http://lwn.net/Articles/632058/

I'm not saying this works as-is for you, but people are starting to
add bus properties to buses.

>> >> Also, I feel like we are using DT to work around kernel policy (of
>> >> turning off clocks). If the policy was to leave on clocks, then we
>> >> would be trying to put a list of clocks to disable in DT.
>> >
>> > I'm not sure I understand your point.  The current policy is correct
>> > if it's power that you care about, which is invariably the point of
>> > disabling clocks in the first place, right?  Also, this has nothing to
>> > do with DT per say.  It's just another framework driver.
>>
>> It does have something to do with DT because you are designing a
>> binding around what the kernel does. Should the kernel assume it can
>> disable clocks safely?
>
> I guess it depends on what you're trying to achieve.  Personally I
> think the kernel's policy is a good one, especually with regards to
> power saving.  What are you suggesting?  A new policy?

No. The binding just has to work no matter what the OS policy.

>> Another OS may do the opposite and assume it
>> cannot turn-off unused clocks. Then you would have a list of clocks
>> safe to disable in DT.
>
> Sounds bananas.  What's good about that kind of policy?  It wouldn't
> matter anyway, both of these implementations can live harmoniously in
> the same tree.

Your systems won't go *boom*.

>> This is also completely solvable within the framework driver by
>> claiming those clocks in the clock controller driver.
>
> This conversation has now gone full circle.  This was an earlier
> suggestion, but it was considered hacky, and I'm inclined to agree.

The clock maintainer doesn't want hacks in the clock framework and the
DT maintainer doesn't want them in DT... We should put them in MFD. ;)

> An always-on power domain was deemed to be a much more elegant
> solution.

Now you are mixing in power domains?

I'm not saying we can't put something in DT. I'm okay with that, but
it needs to handle the case of the clocks do get claimed either after
boot (e.g. by a module) or in later kernels without a dtb change.

Rob

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Geert Uytterhoeven]

Hi Lee,

On Wed, Feb 18, 2015 at 10:54 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > +Some hardware is contains bunches of clocks which must never be
>> >> > +turned off.  If drivers a) fail to obtain a reference to any of
>> >> > +these or b) give up a previously obtained reference during suspend,
>> >> > +the common clk framework will attempt to disable them and the
>> >> > +hardware can fail irrecoverably.  Usually, the only way to recover
>> >> > +from these failures is to restart.
>> >>
>> >> How is (b) not a bug?
>> >
>> > Clocks are normally disabled during suspend.  When clocks are disabled
>> > they give up their reference.  If references reach 0, the clock is
>> > gated.  If one of these clocks is gated, the system will never come
>> > out of suspend.
>> >
>> > How is it a bug?
>>
>> It a clock needs to be enabled during suspend, then the driver using
>> it should not disable it. Anyway, suspend is a bit orthogonal to this
>> issue.
>
> IMO, it's not the driver's responsibility to know which clock they are
> using and whether it's a critical clock or not.

So it's (partly) a platform/bus issue.

>> >> While I think we need something here, I worry that this will be abused
>> >> to be a list of clocks you have not gotten around to managing. We
>> >
>> > You can say that about any framework.  It's our responsibility to ask
>> > the right questions and to disallow it from being abused.  The clocks
>> > I use in the (real-world) example in this set are _really_ always-on.
>> > If any of them are turned off the system will cease to perform in any
>> > meaningful way.
>>
>> You cannot tell here up front whether clocks are really always-on. A
>> reviewer is not going to know, and the submitter may not even have all
>> the documentation and know the answer. Getting it wrong here means you
>> have to change the dtb to fix it. Granted, it doesn't really break
>> things in this case.
>
> We should make it clear in the documentation that this framework
> should only be used if the clock is a critical "if it's turned off it
> will cripple the system" one.

[...]

> I think the kernel's policy is a good one i.e. wait until all devices
> are probed and have had the opportunity to take the clocks they need,
> at which point we can usually safely gate the remainder.  These types
> of clocks are the exception however; hence the need for this driver.
> There are other vendors which have similar issues with their h/w.
> These are currently using bespoke versions of this implementation, but
> IMO a generic solution would be better.

What kind of clocks are these? What do they control?
Memory controllers? Bus controllers?

They must control some device(s), so there should be one or more device
nodes in DT that reference these clocks.
As soon as that information is in DT, support can be added to Linux to
make sure the "critical" clocks stay enabled, either through a real driver,
or through platform code.

>> Does simple-pm-bus help you?
>
> I have no idea what this is, and I'm struggling to grep for it too?

Rob already provided a pointer.
If you have more questions, feel free to ask!

Gr{oetje,eeting}s,

                        Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> On Wed, Feb 18, 2015 at 10:54 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> > +Some hardware is contains bunches of clocks which must never be
> >> >> > +turned off.  If drivers a) fail to obtain a reference to any of
> >> >> > +these or b) give up a previously obtained reference during suspend,
> >> >> > +the common clk framework will attempt to disable them and the
> >> >> > +hardware can fail irrecoverably.  Usually, the only way to recover
> >> >> > +from these failures is to restart.
> >> >>
> >> >> How is (b) not a bug?
> >> >
> >> > Clocks are normally disabled during suspend.  When clocks are disabled
> >> > they give up their reference.  If references reach 0, the clock is
> >> > gated.  If one of these clocks is gated, the system will never come
> >> > out of suspend.
> >> >
> >> > How is it a bug?
> >>
> >> It a clock needs to be enabled during suspend, then the driver using
> >> it should not disable it. Anyway, suspend is a bit orthogonal to this
> >> issue.
> >
> > IMO, it's not the driver's responsibility to know which clock they are
> > using and whether it's a critical clock or not.
> 
> So it's (partly) a platform/bus issue.
> 
> >> >> While I think we need something here, I worry that this will be abused
> >> >> to be a list of clocks you have not gotten around to managing. We
> >> >
> >> > You can say that about any framework.  It's our responsibility to ask
> >> > the right questions and to disallow it from being abused.  The clocks
> >> > I use in the (real-world) example in this set are _really_ always-on.
> >> > If any of them are turned off the system will cease to perform in any
> >> > meaningful way.
> >>
> >> You cannot tell here up front whether clocks are really always-on. A
> >> reviewer is not going to know, and the submitter may not even have all
> >> the documentation and know the answer. Getting it wrong here means you
> >> have to change the dtb to fix it. Granted, it doesn't really break
> >> things in this case.
> >
> > We should make it clear in the documentation that this framework
> > should only be used if the clock is a critical "if it's turned off it
> > will cripple the system" one.
> 
> [...]
> 
> > I think the kernel's policy is a good one i.e. wait until all devices
> > are probed and have had the opportunity to take the clocks they need,
> > at which point we can usually safely gate the remainder.  These types
> > of clocks are the exception however; hence the need for this driver.
> > There are other vendors which have similar issues with their h/w.
> > These are currently using bespoke versions of this implementation, but
> > IMO a generic solution would be better.
> 
> What kind of clocks are these? What do they control?
> Memory controllers? Bus controllers?
> 
> They must control some device(s), so there should be one or more device
> nodes in DT that reference these clocks.
> As soon as that information is in DT, support can be added to Linux to
> make sure the "critical" clocks stay enabled, either through a real driver,
> or through platform code.

Some do, some don't.  For instance, we have one clock which controls
SPI and I2C that must not be turned off.  We discovered this then when
a suspend was attempted and the board refused to resume.  This clock
also runs one of the critical interconnects that runs from the a9.  It
would be wrong to remove the clk_disable() attempt from the SPI/I2C
drivers because the same IP on another board might be controlled by a
different clock which is able to be gated.

There are also clocks which control other interconnects that are not
connected to any device drivers.  If we fail to take references for
them before clk_disable_unused() is called, again the board hangs.  We
even lose JTAG support.

> >> Does simple-pm-bus help you?
> >
> > I have no idea what this is, and I'm struggling to grep for it too?
> 
> Rob already provided a pointer.
> If you have more questions, feel free to ask!

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Geert Uytterhoeven]

Hi Lee,

On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> What kind of clocks are these? What do they control?
>> Memory controllers? Bus controllers?
>>
>> They must control some device(s), so there should be one or more device
>> nodes in DT that reference these clocks.
>> As soon as that information is in DT, support can be added to Linux to
>> make sure the "critical" clocks stay enabled, either through a real driver,
>> or through platform code.
>
> Some do, some don't.  For instance, we have one clock which controls
> SPI and I2C that must not be turned off.  We discovered this then when
> a suspend was attempted and the board refused to resume.  This clock
> also runs one of the critical interconnects that runs from the a9.  It
> would be wrong to remove the clk_disable() attempt from the SPI/I2C
> drivers because the same IP on another board might be controlled by a
> different clock which is able to be gated.
>
> There are also clocks which control other interconnects that are not
> connected to any device drivers.  If we fail to take references for
> them before clk_disable_unused() is called, again the board hangs.  We
> even lose JTAG support.

Interconnects are buses. Can't you represent those buses in the DT
hierarchy, and give them clocks properties?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Wed, 18 Feb 2015, Rob Herring wrote:
> On Wed, Feb 18, 2015 at 3:54 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 18 Feb 2015, Rob Herring wrote:
> >
> >> On Wed, Feb 18, 2015 at 11:12 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > On Wed, 18 Feb 2015, Rob Herring wrote:
> >> >
> >> >> On Wed, Feb 18, 2015 at 10:15 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >> >> > ---
> >> >> >  .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++++++++++++
> >> >> >  1 file changed, 35 insertions(+)
> >> >> >  create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
> >> >> >
> >> >> > diff --git a/Documentation/devicetree/bindings/clock/clk-domain.txt b/Documentation/devicetree/bindings/clock/clk-domain.txt
> >> >> > new file mode 100644
> >> >> > index 0000000..b86772f5
> >> >> > --- /dev/null
> >> >> > +++ b/Documentation/devicetree/bindings/clock/clk-domain.txt
> >> >> > @@ -0,0 +1,35 @@
> >> >> > +Always-on Clock Domain
> >> >> > +
> >> >> > +Some hardware is contains bunches of clocks which must never be
> >> >> > +turned off.  If drivers a) fail to obtain a reference to any of
> >> >> > +these or b) give up a previously obtained reference during suspend,
> >> >> > +the common clk framework will attempt to disable them and the
> >> >> > +hardware can fail irrecoverably.  Usually, the only way to recover
> >> >> > +from these failures is to restart.
> >> >>
> >> >> How is (b) not a bug?
> >> >
> >> > Clocks are normally disabled during suspend.  When clocks are disabled
> >> > they give up their reference.  If references reach 0, the clock is
> >> > gated.  If one of these clocks is gated, the system will never come
> >> > out of suspend.
> >> >
> >> > How is it a bug?
> >>
> >> It a clock needs to be enabled during suspend, then the driver using
> >> it should not disable it. Anyway, suspend is a bit orthogonal to this
> >> issue.
> >
> > IMO, it's not the driver's responsibility to know which clock they are
> > using and whether it's a critical clock or not.
> 
> Certainly drivers should not know about clocks outside of their h/w
> block, but they absolutely should know if a clock is needed for
> wake-up.
> 
> >> >> While I think we need something here, I worry that this will be abused
> >> >> to be a list of clocks you have not gotten around to managing. We
> >> >
> >> > You can say that about any framework.  It's our responsibility to ask
> >> > the right questions and to disallow it from being abused.  The clocks
> >> > I use in the (real-world) example in this set are _really_ always-on.
> >> > If any of them are turned off the system will cease to perform in any
> >> > meaningful way.
> >>
> >> You cannot tell here up front whether clocks are really always-on. A
> >> reviewer is not going to know, and the submitter may not even have all
> >> the documentation and know the answer. Getting it wrong here means you
> >> have to change the dtb to fix it. Granted, it doesn't really break
> >> things in this case.
> >
> > We should make it clear in the documentation that this framework
> > should only be used if the clock is a critical "if it's turned off it
> > will cripple the system" one.
> >
> >> >> cannot be changing the DT every time the kernel starts managing a
> >> >> clock. I think this should operate more as always on until claimed.
> >> >
> >> > The point of this is that even when these clocks are claimed, there is
> >> > an issue that when unclaimed (i.e. during suspend) the clk framework
> >> > will attempt to gate them, and when they do *boom*.
> >> >
> >> >> But then you get into drivers having to be aware that the clock
> >> >> started enabled.
> >> >
> >> > This has nothing to do with the initial state of the clock.  It's
> >> > whether the clock is integral (i.e. is part of a vital interconnect)
> >> > that's important.  For instance, ST's bootloader turns on lots of
> >> > clocks which can be safely gated if unused.  The clocks we're
> >> > registering with this always-on framework cannot.
> >>
> >> It does because you have to assume either the initial state is wrong
> >> and you need to disable it, or that the initial state is correct and
> >> you need to leave the clock enabled.
> >
> > I think the kernel's policy is a good one i.e. wait until all devices
> > are probed and have had the opportunity to take the clocks they need,
> > at which point we can usually safely gate the remainder.  These types
> > of clocks are the exception however; hence the need for this driver.
> > There are other vendors which have similar issues with their h/w.
> > These are currently using bespoke versions of this implementation, but
> > IMO a generic solution would be better.
> >
> >> There are also other usecases such as simplefb where you want to leave
> >> clocks on until the real fb driver takes over. Consoles have a similar
> >> issue.
> >
> > Why wouldn't these devices have taken references by the time
> > clk_disable_unused() is called?
> 
> Not if the drivers are modules.

Can you rightfully compile the drivers for your monitor and serial
console as modules and expect them to work until you load them?

> >> Perhaps you need to model your buses more completely?
> >
> > Would you mind explaining this a little more please?
> >
> >> Does simple-pm-bus help you?
> >
> > I have no idea what this is, and I'm struggling to grep for it too?
> 
> http://lwn.net/Articles/632058/
> 
> I'm not saying this works as-is for you, but people are starting to
> add bus properties to buses.

I'm struggling to see how this might help.  Which node would you probe
as simple-pm-bus?  It sounds like a very bloated and convoluted way
of saying "don't gate these clocks".  Besides, isn't this the opposite
what what we're trying to achieve?  We don't want to enable any PM on
these clocks, let along runtime PM.  FYI, I also looked into genpd,
but came to the same set of conclusions.

> >> >> Also, I feel like we are using DT to work around kernel policy (of
> >> >> turning off clocks). If the policy was to leave on clocks, then we
> >> >> would be trying to put a list of clocks to disable in DT.
> >> >
> >> > I'm not sure I understand your point.  The current policy is correct
> >> > if it's power that you care about, which is invariably the point of
> >> > disabling clocks in the first place, right?  Also, this has nothing to
> >> > do with DT per say.  It's just another framework driver.
> >>
> >> It does have something to do with DT because you are designing a
> >> binding around what the kernel does. Should the kernel assume it can
> >> disable clocks safely?
> >
> > I guess it depends on what you're trying to achieve.  Personally I
> > think the kernel's policy is a good one, especually with regards to
> > power saving.  What are you suggesting?  A new policy?
> 
> No. The binding just has to work no matter what the OS policy.
> 
> >> Another OS may do the opposite and assume it
> >> cannot turn-off unused clocks. Then you would have a list of clocks
> >> safe to disable in DT.
> >
> > Sounds bananas.  What's good about that kind of policy?  It wouldn't
> > matter anyway, both of these implementations can live harmoniously in
> > the same tree.
> 
> Your systems won't go *boom*.
> 
> >> This is also completely solvable within the framework driver by
> >> claiming those clocks in the clock controller driver.
> >
> > This conversation has now gone full circle.  This was an earlier
> > suggestion, but it was considered hacky, and I'm inclined to agree.
> 
> The clock maintainer doesn't want hacks in the clock framework and the
> DT maintainer doesn't want them in DT... We should put them in MFD. ;)
> 
> > An always-on power domain was deemed to be a much more elegant
> > solution.
> 
> Now you are mixing in power domains?
> 
> I'm not saying we can't put something in DT. I'm okay with that, but
> it needs to handle the case of the clocks do get claimed either after
> boot (e.g. by a module) or in later kernels without a dtb change.
> 
> Rob

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> What kind of clocks are these? What do they control?
> >> Memory controllers? Bus controllers?
> >>
> >> They must control some device(s), so there should be one or more device
> >> nodes in DT that reference these clocks.
> >> As soon as that information is in DT, support can be added to Linux to
> >> make sure the "critical" clocks stay enabled, either through a real driver,
> >> or through platform code.
> >
> > Some do, some don't.  For instance, we have one clock which controls
> > SPI and I2C that must not be turned off.  We discovered this then when
> > a suspend was attempted and the board refused to resume.  This clock
> > also runs one of the critical interconnects that runs from the a9.  It
> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
> > drivers because the same IP on another board might be controlled by a
> > different clock which is able to be gated.
> >
> > There are also clocks which control other interconnects that are not
> > connected to any device drivers.  If we fail to take references for
> > them before clk_disable_unused() is called, again the board hangs.  We
> > even lose JTAG support.
> 
> Interconnects are buses. Can't you represent those buses in the DT
> hierarchy, and give them clocks properties?

So instead of this nice succinct, simple, cover all bases
(interconnects was just an example, there are bound to be others),
generic framework, you are suggesting to write drivers for devices
which other than "don't turn my clocks off", Linux can't actually see
or control?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Geert Uytterhoeven]

Hi Lee,

On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> >> What kind of clocks are these? What do they control?
>> >> Memory controllers? Bus controllers?
>> >>
>> >> They must control some device(s), so there should be one or more device
>> >> nodes in DT that reference these clocks.
>> >> As soon as that information is in DT, support can be added to Linux to
>> >> make sure the "critical" clocks stay enabled, either through a real driver,
>> >> or through platform code.
>> >
>> > Some do, some don't.  For instance, we have one clock which controls
>> > SPI and I2C that must not be turned off.  We discovered this then when
>> > a suspend was attempted and the board refused to resume.  This clock
>> > also runs one of the critical interconnects that runs from the a9.  It
>> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
>> > drivers because the same IP on another board might be controlled by a
>> > different clock which is able to be gated.
>> >
>> > There are also clocks which control other interconnects that are not
>> > connected to any device drivers.  If we fail to take references for
>> > them before clk_disable_unused() is called, again the board hangs.  We
>> > even lose JTAG support.
>>
>> Interconnects are buses. Can't you represent those buses in the DT
>> hierarchy, and give them clocks properties?
>
> So instead of this nice succinct, simple, cover all bases
> (interconnects was just an example, there are bound to be others),
> generic framework, you are suggesting to write drivers for devices
> which other than "don't turn my clocks off", Linux can't actually see
> or control?

DT describes the hardware, not behavior.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> >> What kind of clocks are these? What do they control?
> >> >> Memory controllers? Bus controllers?
> >> >>
> >> >> They must control some device(s), so there should be one or more device
> >> >> nodes in DT that reference these clocks.
> >> >> As soon as that information is in DT, support can be added to Linux to
> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
> >> >> or through platform code.
> >> >
> >> > Some do, some don't.  For instance, we have one clock which controls
> >> > SPI and I2C that must not be turned off.  We discovered this then when
> >> > a suspend was attempted and the board refused to resume.  This clock
> >> > also runs one of the critical interconnects that runs from the a9.  It
> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
> >> > drivers because the same IP on another board might be controlled by a
> >> > different clock which is able to be gated.
> >> >
> >> > There are also clocks which control other interconnects that are not
> >> > connected to any device drivers.  If we fail to take references for
> >> > them before clk_disable_unused() is called, again the board hangs.  We
> >> > even lose JTAG support.
> >>
> >> Interconnects are buses. Can't you represent those buses in the DT
> >> hierarchy, and give them clocks properties?
> >
> > So instead of this nice succinct, simple, cover all bases
> > (interconnects was just an example, there are bound to be others),
> > generic framework, you are suggesting to write drivers for devices
> > which other than "don't turn my clocks off", Linux can't actually see
> > or control?
> 
> DT describes the hardware, not behavior.

Okay so ...

/*
 * ICNs are not visible/controllable in Linux, but references to their
 * clocks must be obtained and retained or the platform will become
 * irrecoverably unresponsive.
 */
interconnects@0 {
       compatible = "always-on-clk-domain";
       clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
                <&clk_s_c0_flexgen CLK_ICN_LMI>,
                <&clk_s_c0_flexgen CLK_ICN_CPU>,
                <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Geert Uytterhoeven]

Hi Lee,

On Thu, Feb 19, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> >> What kind of clocks are these? What do they control?
>> >> >> Memory controllers? Bus controllers?
>> >> >>
>> >> >> They must control some device(s), so there should be one or more device
>> >> >> nodes in DT that reference these clocks.
>> >> >> As soon as that information is in DT, support can be added to Linux to
>> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
>> >> >> or through platform code.
>> >> >
>> >> > Some do, some don't.  For instance, we have one clock which controls
>> >> > SPI and I2C that must not be turned off.  We discovered this then when
>> >> > a suspend was attempted and the board refused to resume.  This clock
>> >> > also runs one of the critical interconnects that runs from the a9.  It
>> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
>> >> > drivers because the same IP on another board might be controlled by a
>> >> > different clock which is able to be gated.
>> >> >
>> >> > There are also clocks which control other interconnects that are not
>> >> > connected to any device drivers.  If we fail to take references for
>> >> > them before clk_disable_unused() is called, again the board hangs.  We
>> >> > even lose JTAG support.
>> >>
>> >> Interconnects are buses. Can't you represent those buses in the DT
>> >> hierarchy, and give them clocks properties?
>> >
>> > So instead of this nice succinct, simple, cover all bases
>> > (interconnects was just an example, there are bound to be others),
>> > generic framework, you are suggesting to write drivers for devices
>> > which other than "don't turn my clocks off", Linux can't actually see
>> > or control?
>>
>> DT describes the hardware, not behavior.
>
> Okay so ...
>
> /*
>  * ICNs are not visible/controllable in Linux, but references to their
>  * clocks must be obtained and retained or the platform will become
>  * irrecoverably unresponsive.
>  */
> interconnects@0 {
>        compatible = "always-on-clk-domain";

st,...flexgen...

>        clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
>                 <&clk_s_c0_flexgen CLK_ICN_LMI>,
>                 <&clk_s_c0_flexgen CLK_ICN_CPU>,
>                 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
> };

And then you can have platform code that binds against st,...flexgen...,
and enables all referenced clocks.

Alternatively, if you have power domains, you can add a reference to
the power domain, and let the power domain driver handle it.

Gr{oetje,eeting}s,

                        Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Feb 19, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> >> What kind of clocks are these? What do they control?
> >> >> >> Memory controllers? Bus controllers?
> >> >> >>
> >> >> >> They must control some device(s), so there should be one or more device
> >> >> >> nodes in DT that reference these clocks.
> >> >> >> As soon as that information is in DT, support can be added to Linux to
> >> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
> >> >> >> or through platform code.
> >> >> >
> >> >> > Some do, some don't.  For instance, we have one clock which controls
> >> >> > SPI and I2C that must not be turned off.  We discovered this then when
> >> >> > a suspend was attempted and the board refused to resume.  This clock
> >> >> > also runs one of the critical interconnects that runs from the a9.  It
> >> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
> >> >> > drivers because the same IP on another board might be controlled by a
> >> >> > different clock which is able to be gated.
> >> >> >
> >> >> > There are also clocks which control other interconnects that are not
> >> >> > connected to any device drivers.  If we fail to take references for
> >> >> > them before clk_disable_unused() is called, again the board hangs.  We
> >> >> > even lose JTAG support.
> >> >>
> >> >> Interconnects are buses. Can't you represent those buses in the DT
> >> >> hierarchy, and give them clocks properties?
> >> >
> >> > So instead of this nice succinct, simple, cover all bases
> >> > (interconnects was just an example, there are bound to be others),
> >> > generic framework, you are suggesting to write drivers for devices
> >> > which other than "don't turn my clocks off", Linux can't actually see
> >> > or control?
> >>
> >> DT describes the hardware, not behavior.
> >
> > Okay so ...
> >
> > /*
> >  * ICNs are not visible/controllable in Linux, but references to their
> >  * clocks must be obtained and retained or the platform will become
> >  * irrecoverably unresponsive.
> >  */
> > interconnects@0 {
> >        compatible = "always-on-clk-domain";
> 
> st,...flexgen...
> 
> >        clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
> >                 <&clk_s_c0_flexgen CLK_ICN_LMI>,
> >                 <&clk_s_c0_flexgen CLK_ICN_CPU>,
> >                 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
> > };
> 
> And then you can have platform code that binds against st,...flexgen...,
> and enables all referenced clocks.

Flexgen isn't a device, it's a clk source.  a) writing a device driver
for a clk source seems wrong b) what if on another platform a
different clock source supplied the clock?  Write another driver?  And
what if the ICNs are connected to different clock sources?  More
drivers?  c) all of these drivers will only do one thing -- pull a
reference and keep hold of it.  You want 50 drivers (across all
platforms) doing only that?  Or, more sanely, do you want this one
generic framework driver doing that?

> Alternatively, if you have power domains, you can add a reference to
> the power domain, and let the power domain driver handle it.

I'm not sure what a power domain driver will do?  We need a driver to
_not_ give up references, that is all. :)

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Geert Uytterhoeven]

Hi Lee,

On Thu, Feb 19, 2015 at 11:43 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> On Thu, Feb 19, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> >> >> What kind of clocks are these? What do they control?
>> >> >> >> Memory controllers? Bus controllers?
>> >> >> >>
>> >> >> >> They must control some device(s), so there should be one or more device
>> >> >> >> nodes in DT that reference these clocks.
>> >> >> >> As soon as that information is in DT, support can be added to Linux to
>> >> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
>> >> >> >> or through platform code.
>> >> >> >
>> >> >> > Some do, some don't.  For instance, we have one clock which controls
>> >> >> > SPI and I2C that must not be turned off.  We discovered this then when
>> >> >> > a suspend was attempted and the board refused to resume.  This clock
>> >> >> > also runs one of the critical interconnects that runs from the a9.  It
>> >> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
>> >> >> > drivers because the same IP on another board might be controlled by a
>> >> >> > different clock which is able to be gated.
>> >> >> >
>> >> >> > There are also clocks which control other interconnects that are not
>> >> >> > connected to any device drivers.  If we fail to take references for
>> >> >> > them before clk_disable_unused() is called, again the board hangs.  We
>> >> >> > even lose JTAG support.
>> >> >>
>> >> >> Interconnects are buses. Can't you represent those buses in the DT
>> >> >> hierarchy, and give them clocks properties?
>> >> >
>> >> > So instead of this nice succinct, simple, cover all bases
>> >> > (interconnects was just an example, there are bound to be others),
>> >> > generic framework, you are suggesting to write drivers for devices
>> >> > which other than "don't turn my clocks off", Linux can't actually see
>> >> > or control?
>> >>
>> >> DT describes the hardware, not behavior.
>> >
>> > Okay so ...
>> >
>> > /*
>> >  * ICNs are not visible/controllable in Linux, but references to their
>> >  * clocks must be obtained and retained or the platform will become
>> >  * irrecoverably unresponsive.
>> >  */
>> > interconnects@0 {
>> >        compatible = "always-on-clk-domain";
>>
>> st,...flexgen...
>>
>> >        clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
>> >                 <&clk_s_c0_flexgen CLK_ICN_LMI>,
>> >                 <&clk_s_c0_flexgen CLK_ICN_CPU>,
>> >                 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
>> > };
>>
>> And then you can have platform code that binds against st,...flexgen...,
>> and enables all referenced clocks.
>
> Flexgen isn't a device, it's a clk source.  a) writing a device driver

Sorry, I'm not familiar with ST nomenclature.
So that should become the name of the interconnect/bus.

> for a clk source seems wrong b) what if on another platform a
> different clock source supplied the clock?  Write another driver?  And
> what if the ICNs are connected to different clock sources?  More
> drivers?  c) all of these drivers will only do one thing -- pull a
> reference and keep hold of it.  You want 50 drivers (across all
> platforms) doing only that?  Or, more sanely, do you want this one
> generic framework driver doing that?
>
>> Alternatively, if you have power domains, you can add a reference to
>> the power domain, and let the power domain driver handle it.
>
> I'm not sure what a power domain driver will do?  We need a driver to
> _not_ give up references, that is all. :)

A power domain driver can do anything it wants.
That includes enabling your interconnect clocks, and keeping them enabled.

Now, if flexgen is the name of the clock source, then all devices connected
to flexgen are part of the flexgen clock domain, which can be represented
in Linux using the generic PM domain. Do all devices connected to flexgen
need to be handled similarly w.r.t. clocks? If yes, the genpd may be the place
to implement that.

Gr{oetje,eeting}s,

                        Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> On Thu, Feb 19, 2015 at 11:43 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> On Thu, Feb 19, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> >> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
> >> >> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> >> >> What kind of clocks are these? What do they control?
> >> >> >> >> Memory controllers? Bus controllers?
> >> >> >> >>
> >> >> >> >> They must control some device(s), so there should be one or more device
> >> >> >> >> nodes in DT that reference these clocks.
> >> >> >> >> As soon as that information is in DT, support can be added to Linux to
> >> >> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
> >> >> >> >> or through platform code.
> >> >> >> >
> >> >> >> > Some do, some don't.  For instance, we have one clock which controls
> >> >> >> > SPI and I2C that must not be turned off.  We discovered this then when
> >> >> >> > a suspend was attempted and the board refused to resume.  This clock
> >> >> >> > also runs one of the critical interconnects that runs from the a9.  It
> >> >> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
> >> >> >> > drivers because the same IP on another board might be controlled by a
> >> >> >> > different clock which is able to be gated.
> >> >> >> >
> >> >> >> > There are also clocks which control other interconnects that are not
> >> >> >> > connected to any device drivers.  If we fail to take references for
> >> >> >> > them before clk_disable_unused() is called, again the board hangs.  We
> >> >> >> > even lose JTAG support.
> >> >> >>
> >> >> >> Interconnects are buses. Can't you represent those buses in the DT
> >> >> >> hierarchy, and give them clocks properties?
> >> >> >
> >> >> > So instead of this nice succinct, simple, cover all bases
> >> >> > (interconnects was just an example, there are bound to be others),
> >> >> > generic framework, you are suggesting to write drivers for devices
> >> >> > which other than "don't turn my clocks off", Linux can't actually see
> >> >> > or control?
> >> >>
> >> >> DT describes the hardware, not behavior.
> >> >
> >> > Okay so ...
> >> >
> >> > /*
> >> >  * ICNs are not visible/controllable in Linux, but references to their
> >> >  * clocks must be obtained and retained or the platform will become
> >> >  * irrecoverably unresponsive.
> >> >  */
> >> > interconnects@0 {
> >> >        compatible = "always-on-clk-domain";
> >>
> >> st,...flexgen...
> >>
> >> >        clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
> >> >                 <&clk_s_c0_flexgen CLK_ICN_LMI>,
> >> >                 <&clk_s_c0_flexgen CLK_ICN_CPU>,
> >> >                 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
> >> > };
> >>
> >> And then you can have platform code that binds against st,...flexgen...,
> >> and enables all referenced clocks.
> >
> > Flexgen isn't a device, it's a clk source.  a) writing a device driver
> 
> Sorry, I'm not familiar with ST nomenclature.
> So that should become the name of the interconnect/bus.

You're still talking about writing function-less drivers for multiple
pieces of h/w.  We would have a few for ST alone, then multiply that
by the number of silicon vendors with similar issues -- which is
likely to be most of them.

I can understand Rob's "DT has to match h/w" point, but to insist we
write lots of empty drivers just to stop some clocks from being gated
is barking mad.

> > for a clk source seems wrong b) what if on another platform a
> > different clock source supplied the clock?  Write another driver?  And
> > what if the ICNs are connected to different clock sources?  More
> > drivers?  c) all of these drivers will only do one thing -- pull a
> > reference and keep hold of it.  You want 50 drivers (across all
> > platforms) doing only that?  Or, more sanely, do you want this one
> > generic framework driver doing that?
> >
> >> Alternatively, if you have power domains, you can add a reference to
> >> the power domain, and let the power domain driver handle it.
> >
> > I'm not sure what a power domain driver will do?  We need a driver to
> > _not_ give up references, that is all. :)
> 
> A power domain driver can do anything it wants.
> That includes enabling your interconnect clocks, and keeping them enabled.
> 
> Now, if flexgen is the name of the clock source, then all devices connected
> to flexgen are part of the flexgen clock domain, which can be represented
> in Linux using the generic PM domain. Do all devices connected to flexgen
> need to be handled similarly w.r.t. clocks? If yes, the genpd may be the place
> to implement that.

Most of the FLEXGEN clocks are fully gateable.  It's only a select few
which are critical to the running of the system.

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

Re: [PATCH v2 4/4] clk: dt: Introduce always-on clock domain documentation

[Rob Herring]

On Thu, Feb 19, 2015 at 5:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> On Thu, Feb 19, 2015 at 11:43 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> On Thu, Feb 19, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> >> On Thu, Feb 19, 2015 at 11:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> >> > On Thu, 19 Feb 2015, Geert Uytterhoeven wrote:
>> >> >> >> On Thu, Feb 19, 2015 at 10:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> >> >> >> What kind of clocks are these? What do they control?
>> >> >> >> >> Memory controllers? Bus controllers?
>> >> >> >> >>
>> >> >> >> >> They must control some device(s), so there should be one or more device
>> >> >> >> >> nodes in DT that reference these clocks.
>> >> >> >> >> As soon as that information is in DT, support can be added to Linux to
>> >> >> >> >> make sure the "critical" clocks stay enabled, either through a real driver,
>> >> >> >> >> or through platform code.
>> >> >> >> >
>> >> >> >> > Some do, some don't.  For instance, we have one clock which controls
>> >> >> >> > SPI and I2C that must not be turned off.  We discovered this then when
>> >> >> >> > a suspend was attempted and the board refused to resume.  This clock
>> >> >> >> > also runs one of the critical interconnects that runs from the a9.  It
>> >> >> >> > would be wrong to remove the clk_disable() attempt from the SPI/I2C
>> >> >> >> > drivers because the same IP on another board might be controlled by a
>> >> >> >> > different clock which is able to be gated.
>> >> >> >> >
>> >> >> >> > There are also clocks which control other interconnects that are not
>> >> >> >> > connected to any device drivers.  If we fail to take references for
>> >> >> >> > them before clk_disable_unused() is called, again the board hangs.  We
>> >> >> >> > even lose JTAG support.
>> >> >> >>
>> >> >> >> Interconnects are buses. Can't you represent those buses in the DT
>> >> >> >> hierarchy, and give them clocks properties?
>> >> >> >
>> >> >> > So instead of this nice succinct, simple, cover all bases
>> >> >> > (interconnects was just an example, there are bound to be others),
>> >> >> > generic framework, you are suggesting to write drivers for devices
>> >> >> > which other than "don't turn my clocks off", Linux can't actually see
>> >> >> > or control?
>> >> >>
>> >> >> DT describes the hardware, not behavior.
>> >> >
>> >> > Okay so ...
>> >> >
>> >> > /*
>> >> >  * ICNs are not visible/controllable in Linux, but references to their
>> >> >  * clocks must be obtained and retained or the platform will become
>> >> >  * irrecoverably unresponsive.
>> >> >  */
>> >> > interconnects@0 {
>> >> >        compatible = "always-on-clk-domain";
>> >>
>> >> st,...flexgen...
>> >>
>> >> >        clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
>> >> >                 <&clk_s_c0_flexgen CLK_ICN_LMI>,
>> >> >                 <&clk_s_c0_flexgen CLK_ICN_CPU>,
>> >> >                 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>;
>> >> > };
>> >>
>> >> And then you can have platform code that binds against st,...flexgen...,
>> >> and enables all referenced clocks.
>> >
>> > Flexgen isn't a device, it's a clk source.  a) writing a device driver
>>
>> Sorry, I'm not familiar with ST nomenclature.
>> So that should become the name of the interconnect/bus.
>
> You're still talking about writing function-less drivers for multiple
> pieces of h/w.  We would have a few for ST alone, then multiply that
> by the number of silicon vendors with similar issues -- which is
> likely to be most of them.
>
> I can understand Rob's "DT has to match h/w" point, but to insist we
> write lots of empty drivers just to stop some clocks from being gated
> is barking mad.
>
>> > for a clk source seems wrong b) what if on another platform a
>> > different clock source supplied the clock?  Write another driver?  And
>> > what if the ICNs are connected to different clock sources?  More
>> > drivers?  c) all of these drivers will only do one thing -- pull a
>> > reference and keep hold of it.  You want 50 drivers (across all
>> > platforms) doing only that?  Or, more sanely, do you want this one
>> > generic framework driver doing that?
>> >
>> >> Alternatively, if you have power domains, you can add a reference to
>> >> the power domain, and let the power domain driver handle it.
>> >
>> > I'm not sure what a power domain driver will do?  We need a driver to
>> > _not_ give up references, that is all. :)
>>
>> A power domain driver can do anything it wants.
>> That includes enabling your interconnect clocks, and keeping them enabled.
>>
>> Now, if flexgen is the name of the clock source, then all devices connected
>> to flexgen are part of the flexgen clock domain, which can be represented
>> in Linux using the generic PM domain. Do all devices connected to flexgen
>> need to be handled similarly w.r.t. clocks? If yes, the genpd may be the place
>> to implement that.
>
> Most of the FLEXGEN clocks are fully gateable.  It's only a select few
> which are critical to the running of the system.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [STLinux Kernel] [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Peter Griffin]

Hi Lee,

On Wed, 18 Feb 2015, Lee Jones wrote:
> +/*
> + * ST Clock Domain

minor nit, as v2 is a generic driver, comment needs updating.

regards,

Peter.

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Mike Turquette]

Quoting Lee Jones (2015-02-18 08:15:00)
> Much h/w contain clocks which if turned off would prove fatal.  The
> only way to recover is to restart the board(s).  This driver takes
> references to clocks which are required to be always-on in order to
> prevent the common clk framework from trying to turn them off during
> the clk_disabled_unused() procedure.
> 
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/clk/Makefile    |  1 +
>  drivers/clk/clkdomain.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 64 insertions(+)
>  create mode 100644 drivers/clk/clkdomain.c
> 
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index d5fba5b..d9e2718 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAVE_CLK)          += clk-devres.o
>  obj-$(CONFIG_CLKDEV_LOOKUP)    += clkdev.o
>  obj-$(CONFIG_COMMON_CLK)       += clk.o
>  obj-$(CONFIG_COMMON_CLK)       += clk-divider.o
> +obj-$(CONFIG_COMMON_CLK)       += clkdomain.o
>  obj-$(CONFIG_COMMON_CLK)       += clk-fixed-factor.o
>  obj-$(CONFIG_COMMON_CLK)       += clk-fixed-rate.o
>  obj-$(CONFIG_COMMON_CLK)       += clk-gate.o
> diff --git a/drivers/clk/clkdomain.c b/drivers/clk/clkdomain.c
> new file mode 100644
> index 0000000..8c83f99
> --- /dev/null
> +++ b/drivers/clk/clkdomain.c

Naming is hard. I'm not sure clkdomain.c is the best expression. Maybe
clk-alwon.c? I see ALWON used alot amongst hardware people who live in a
world of eight-character naming limitations.

> @@ -0,0 +1,63 @@
> +/*
> + * ST Clock Domain
> + *
> + * Copyright (C) 2015 STMicroelectronics – All Rights Reserved
> + *
> + * Author: Lee Jones <lee.jones@linaro.org>
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/clk-private.h>

If this header still existed I would berate you mercilessly. Luckily for
you it no longer exists and only causes a compile error ;-)

> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static void ao_clock_domain_hog_clock(struct platform_device *pdev, int index)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       struct clk *clk;
> +       int ret;
> +
> +       clk = of_clk_get(np, index);
> +       if (IS_ERR(clk)) {
> +               dev_warn(&pdev->dev, "Failed get clock %s[%d]: %li\n",
> +                        np->full_name, index, PTR_ERR(clk));
> +               return;
> +       }
> +
> +       ret = clk_prepare_enable(clk);
> +       if (ret)
> +               dev_warn(&pdev->dev, "Failed to enable clock: %s\n", clk->name);
> +}
> +
> +static int ao_clock_domain_probe(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       int nclks, i;
> +
> +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");

Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
minutes writing that function and I need people to use it so I can get a
return on my investment.

Otherwise the patch looks good. I believe that this method is targeting
always-on clock in a production environment, which is different from the
CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
hardware or dealing with a platform that has incomplete driver support.

I wonder if there is a clever way for existing clock providers
(expressed in DT) to use this without having to create a separate node
of clocks with the "always-on-clk-domain" flag. Possibly the common
clock binding could declare some always-on flag that is standardized?
Then the framework core could use this code easily. Not sure if that is
a good idea though...

Regards,
Mike

> +
> +       for (i = 0; i < nclks; i++)
> +               ao_clock_domain_hog_clock(pdev, i);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id ao_clock_domain_match[] = {
> +       { .compatible = "always-on-clk-domain" },
> +       { },
> +};
> +
> +static struct platform_driver ao_clock_domain_driver = {
> +       .probe = ao_clock_domain_probe,
> +       .driver = {
> +               .name = "always-on-clk-domain",
> +               .of_match_table = ao_clock_domain_match,
> +       },
> +};
> +module_platform_driver(ao_clock_domain_driver);
> -- 
> 1.9.1
> 

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Lee Jones]

On Mon, 23 Feb 2015, Mike Turquette wrote:

> Quoting Lee Jones (2015-02-18 08:15:00)
> > Much h/w contain clocks which if turned off would prove fatal.  The
> > only way to recover is to restart the board(s).  This driver takes
> > references to clocks which are required to be always-on in order to
> > prevent the common clk framework from trying to turn them off during
> > the clk_disabled_unused() procedure.
> > 
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  drivers/clk/Makefile    |  1 +
> >  drivers/clk/clkdomain.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 64 insertions(+)
> >  create mode 100644 drivers/clk/clkdomain.c
> > 
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index d5fba5b..d9e2718 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -3,6 +3,7 @@ obj-$(CONFIG_HAVE_CLK)          += clk-devres.o
> >  obj-$(CONFIG_CLKDEV_LOOKUP)    += clkdev.o
> >  obj-$(CONFIG_COMMON_CLK)       += clk.o
> >  obj-$(CONFIG_COMMON_CLK)       += clk-divider.o
> > +obj-$(CONFIG_COMMON_CLK)       += clkdomain.o
> >  obj-$(CONFIG_COMMON_CLK)       += clk-fixed-factor.o
> >  obj-$(CONFIG_COMMON_CLK)       += clk-fixed-rate.o
> >  obj-$(CONFIG_COMMON_CLK)       += clk-gate.o
> > diff --git a/drivers/clk/clkdomain.c b/drivers/clk/clkdomain.c
> > new file mode 100644
> > index 0000000..8c83f99
> > --- /dev/null
> > +++ b/drivers/clk/clkdomain.c
> 
> Naming is hard. I'm not sure clkdomain.c is the best expression. Maybe
> clk-alwon.c? I see ALWON used alot amongst hardware people who live in a
> world of eight-character naming limitations.

If you can have clk-fractional-divider.c in your subsystem, I'm sure
clk-always-on.c will be suitable.

> > @@ -0,0 +1,63 @@
> > +/*
> > + * Always on Clock Domain

=;-)

> > + * Copyright (C) 2015 STMicroelectronics – All Rights Reserved
> > + *
> > + * Author: Lee Jones <lee.jones@linaro.org>
> > + *
> > + * 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; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/clk-private.h>
> 
> If this header still existed I would berate you mercilessly. Luckily for
> you it no longer exists and only causes a compile error ;-)

Noted.

You may wish to update: Documentation/clk.txt accordingly.

> > +#include <linux/clk-provider.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +
> > +static void ao_clock_domain_hog_clock(struct platform_device *pdev, int index)
> > +{
> > +       struct device_node *np = pdev->dev.of_node;
> > +       struct clk *clk;
> > +       int ret;
> > +
> > +       clk = of_clk_get(np, index);
> > +       if (IS_ERR(clk)) {
> > +               dev_warn(&pdev->dev, "Failed get clock %s[%d]: %li\n",
> > +                        np->full_name, index, PTR_ERR(clk));
> > +               return;
> > +       }
> > +
> > +       ret = clk_prepare_enable(clk);
> > +       if (ret)
> > +               dev_warn(&pdev->dev, "Failed to enable clock: %s\n", clk->name);
> > +}
> > +
> > +static int ao_clock_domain_probe(struct platform_device *pdev)
> > +{
> > +       struct device_node *np = pdev->dev.of_node;
> > +       int nclks, i;
> > +
> > +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> 
> Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> minutes writing that function and I need people to use it so I can get a
> return on my investment.

My middle name is RoI.  I'm on it.

> Otherwise the patch looks good. I believe that this method is targeting
> always-on clock in a production environment, which is different from the
> CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> hardware or dealing with a platform that has incomplete driver support.
> 
> I wonder if there is a clever way for existing clock providers
> (expressed in DT) to use this without having to create a separate node
> of clocks with the "always-on-clk-domain" flag. Possibly the common
> clock binding could declare some always-on flag that is standardized?
> Then the framework core could use this code easily. Not sure if that is
> a good idea though...

I think having both would be a good idea.  If all clocks supplied by a
provider should be left on, then a property inside the provider node
could be a good way to describe that.  In our case only some of them
are required, so I consider this concept to be better.

> > +
> > +       for (i = 0; i < nclks; i++)
> > +               ao_clock_domain_hog_clock(pdev, i);
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct of_device_id ao_clock_domain_match[] = {
> > +       { .compatible = "always-on-clk-domain" },
> > +       { },
> > +};
> > +
> > +static struct platform_driver ao_clock_domain_driver = {
> > +       .probe = ao_clock_domain_probe,
> > +       .driver = {
> > +               .name = "always-on-clk-domain",
> > +               .of_match_table = ao_clock_domain_match,
> > +       },
> > +};
> > +module_platform_driver(ao_clock_domain_driver);

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

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Rob Herring]

On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Lee Jones (2015-02-18 08:15:00)
>> Much h/w contain clocks which if turned off would prove fatal.  The
>> only way to recover is to restart the board(s).  This driver takes
>> references to clocks which are required to be always-on in order to
>> prevent the common clk framework from trying to turn them off during
>> the clk_disabled_unused() procedure.

[...]

>> +static int ao_clock_domain_probe(struct platform_device *pdev)
>> +{
>> +       struct device_node *np = pdev->dev.of_node;
>> +       int nclks, i;
>> +
>> +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>
> Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> minutes writing that function and I need people to use it so I can get a
> return on my investment.
>
> Otherwise the patch looks good. I believe that this method is targeting
> always-on clock in a production environment, which is different from the
> CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> hardware or dealing with a platform that has incomplete driver support.

There is also the usecase of keep clocks on until I load a module that
properly handles my hardware (e.g simplefb). We have a simplefb node
with clocks and the simplefb driver jumps thru some hoops to hand-off
clocks to the real driver. I don't really like it and don't want to
see more examples. And there is the case of I thought I would never
manage this clock, but kernel subsystems evolve and now I want to
manage a clock. This should not require a DT update to do so.

Neither of these may be Lee's usecase, but I want to see them covered
by the binding.

> I wonder if there is a clever way for existing clock providers
> (expressed in DT) to use this without having to create a separate node
> of clocks with the "always-on-clk-domain" flag. Possibly the common
> clock binding could declare some always-on flag that is standardized?
> Then the framework core could use this code easily. Not sure if that is
> a good idea though...

I would prefer to see the always on clocks just listed within the
clock controller's node rather than creating made up nodes with clock
properties. This should be always-on until claimed IMO, but that
aspect is the OS's problem, not a DT problem.

Rob

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Lee Jones]

On Wed, 25 Feb 2015, Rob Herring wrote:

> On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Lee Jones (2015-02-18 08:15:00)
> >> Much h/w contain clocks which if turned off would prove fatal.  The
> >> only way to recover is to restart the board(s).  This driver takes
> >> references to clocks which are required to be always-on in order to
> >> prevent the common clk framework from trying to turn them off during
> >> the clk_disabled_unused() procedure.
> 
> [...]
> 
> >> +static int ao_clock_domain_probe(struct platform_device *pdev)
> >> +{
> >> +       struct device_node *np = pdev->dev.of_node;
> >> +       int nclks, i;
> >> +
> >> +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> >
> > Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> > minutes writing that function and I need people to use it so I can get a
> > return on my investment.
> >
> > Otherwise the patch looks good. I believe that this method is targeting
> > always-on clock in a production environment, which is different from the
> > CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> > hardware or dealing with a platform that has incomplete driver support.
> 
> There is also the usecase of keep clocks on until I load a module that
> properly handles my hardware (e.g simplefb). We have a simplefb node
> with clocks and the simplefb driver jumps thru some hoops to hand-off
> clocks to the real driver. I don't really like it and don't want to
> see more examples. And there is the case of I thought I would never
> manage this clock, but kernel subsystems evolve and now I want to
> manage a clock. This should not require a DT update to do so.
> 
> Neither of these may be Lee's usecase, but I want to see them covered
> by the binding.
> 
> > I wonder if there is a clever way for existing clock providers
> > (expressed in DT) to use this without having to create a separate node
> > of clocks with the "always-on-clk-domain" flag. Possibly the common
> > clock binding could declare some always-on flag that is standardized?
> > Then the framework core could use this code easily. Not sure if that is
> > a good idea though...
> 
> I would prefer to see the always on clocks just listed within the
> clock controller's node rather than creating made up nodes with clock
> properties.

> This should be always-on until claimed IMO, but that
> aspect is the OS's problem, not a DT problem.

I disagree with this point.  There are likely to be many unclaimed,
but perfectly gateable clocks in a system, which will consume power
unnecessarily.  The clk framework does the right thing by turning all
unclaimed clocks off IMHO.  This only leaves a small use-case where we
need to artificially claim some which must not be gated.

The other way to do is, as you mentioned is list the clocks which must
stay on in the clock source node, but this will still require a
binding.  It will also require a much more complicated framework
driver.

    clkprovider@xxxxxxxx {
            always-on-clks = <1, 2, 4, 5, 7>;
    };
-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Mike Turquette]

Quoting Rob Herring (2015-02-25 07:24:43)
> On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Lee Jones (2015-02-18 08:15:00)
> >> Much h/w contain clocks which if turned off would prove fatal.  The
> >> only way to recover is to restart the board(s).  This driver takes
> >> references to clocks which are required to be always-on in order to
> >> prevent the common clk framework from trying to turn them off during
> >> the clk_disabled_unused() procedure.
> 
> [...]
> 
> >> +static int ao_clock_domain_probe(struct platform_device *pdev)
> >> +{
> >> +       struct device_node *np = pdev->dev.of_node;
> >> +       int nclks, i;
> >> +
> >> +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> >
> > Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> > minutes writing that function and I need people to use it so I can get a
> > return on my investment.
> >
> > Otherwise the patch looks good. I believe that this method is targeting
> > always-on clock in a production environment, which is different from the
> > CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> > hardware or dealing with a platform that has incomplete driver support.
> 
> There is also the usecase of keep clocks on until I load a module that
> properly handles my hardware (e.g simplefb). We have a simplefb node
> with clocks and the simplefb driver jumps thru some hoops to hand-off
> clocks to the real driver. I don't really like it and don't want to
> see more examples. And there is the case of I thought I would never
> manage this clock, but kernel subsystems evolve and now I want to
> manage a clock. This should not require a DT update to do so.

Regarding the latter case, this is a violation of the intent of
always-on clocks. I think a firmly worded sentence in the binding should
suffice.

> 
> Neither of these may be Lee's usecase, but I want to see them covered
> by the binding.
> 
> > I wonder if there is a clever way for existing clock providers
> > (expressed in DT) to use this without having to create a separate node
> > of clocks with the "always-on-clk-domain" flag. Possibly the common
> > clock binding could declare some always-on flag that is standardized?
> > Then the framework core could use this code easily. Not sure if that is
> > a good idea though...
> 
> I would prefer to see the always on clocks just listed within the
> clock controller's node rather than creating made up nodes with clock
> properties. This should be always-on until claimed IMO, but that
> aspect is the OS's problem, not a DT problem.

So the common clock binding could have a new always-on list added to it,
but the clock can still be claimed and gated by drivers? I'll think on
it a bit but always-on is not the right name in that case. It is a more
general solution however (since it could still cover the sub-case of
clocks always remaining on since a driver never claims them).

Regards,
Mike

> 
> Rob

Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework

[Mike Turquette]

Quoting Lee Jones (2015-02-25 07:48:08)
> On Wed, 25 Feb 2015, Rob Herring wrote:
> 
> > On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > > Quoting Lee Jones (2015-02-18 08:15:00)
> > >> Much h/w contain clocks which if turned off would prove fatal.  The
> > >> only way to recover is to restart the board(s).  This driver takes
> > >> references to clocks which are required to be always-on in order to
> > >> prevent the common clk framework from trying to turn them off during
> > >> the clk_disabled_unused() procedure.
> > 
> > [...]
> > 
> > >> +static int ao_clock_domain_probe(struct platform_device *pdev)
> > >> +{
> > >> +       struct device_node *np = pdev->dev.of_node;
> > >> +       int nclks, i;
> > >> +
> > >> +       nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> > >
> > > Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> > > minutes writing that function and I need people to use it so I can get a
> > > return on my investment.
> > >
> > > Otherwise the patch looks good. I believe that this method is targeting
> > > always-on clock in a production environment, which is different from the
> > > CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> > > hardware or dealing with a platform that has incomplete driver support.
> > 
> > There is also the usecase of keep clocks on until I load a module that
> > properly handles my hardware (e.g simplefb). We have a simplefb node
> > with clocks and the simplefb driver jumps thru some hoops to hand-off
> > clocks to the real driver. I don't really like it and don't want to
> > see more examples. And there is the case of I thought I would never
> > manage this clock, but kernel subsystems evolve and now I want to
> > manage a clock. This should not require a DT update to do so.
> > 
> > Neither of these may be Lee's usecase, but I want to see them covered
> > by the binding.
> > 
> > > I wonder if there is a clever way for existing clock providers
> > > (expressed in DT) to use this without having to create a separate node
> > > of clocks with the "always-on-clk-domain" flag. Possibly the common
> > > clock binding could declare some always-on flag that is standardized?
> > > Then the framework core could use this code easily. Not sure if that is
> > > a good idea though...
> > 
> > I would prefer to see the always on clocks just listed within the
> > clock controller's node rather than creating made up nodes with clock
> > properties.
> 
> > This should be always-on until claimed IMO, but that
> > aspect is the OS's problem, not a DT problem.
> 
> I disagree with this point.  There are likely to be many unclaimed,
> but perfectly gateable clocks in a system, which will consume power
> unnecessarily.  The clk framework does the right thing by turning all
> unclaimed clocks off IMHO.  This only leaves a small use-case where we
> need to artificially claim some which must not be gated.

I might have misread both of your mails, but I think you two are
actually in agreement. You both support a common property which lists
the always-on clocks inside of the common clock binding, no?

> 
> The other way to do is, as you mentioned is list the clocks which must
> stay on in the clock source node, but this will still require a
> binding.  It will also require a much more complicated framework
> driver.
> 
>     clkprovider@xxxxxxxx {
>             always-on-clks = <1, 2, 4, 5, 7>;
>     };

This should pose no burden on the driver. Since always-on-clks is in the
common clock binding it should be handled by the framework core. At
clk_register-time we can check for always-on-clks, walk the list and see
if we have a match. It's ugly O(n^2) but it works.

Thoughts?

Mike

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

(unknown),

[Mr John Wong]

Seeking Your Assistance In A Business Proposal get back to me if interested via email:mrjohn.wong-/E1597aS9LQAvxtiuMwx3w@public.gmane.org

------------------------
This email was scanned by BitDefender.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Robert Smigielski]

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

(unknown),

[Alanoud AlFayeza]

I have a business proposal of a mutual benefit for you, contact for more information

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

(unknown),

[raghu MG]

Hi,
This mail is regarding Linux smp boot on ARMADA-XP MV2860
.

CPU-1 doesnt boot/go through the boot sequence & it fails to come
online & dumps this message

CPU1:failed to come online .

The CPU-1 boot register is programmed with physical address of
-->armada_xp_secondary_startup function & then cpu-0 deasserts the CPU-1.

I am using armada-xp-gp.dts with armada-xp-mv78260.dts included in it.

Any help would be appreciated.
Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Maria McCumiskey]

I and my wife violet donated $500,000.00 USD as our personal donation to you this year 2015.Contact us:
allenlarge0452-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Chunfeng Yun]

>From ac1e8724bfa47494223bad0af450c1a63cd2fe0c Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Wed, 22 Jul 2015 21:15:15 +0800
Subject: [PATCH 0/5] *** SUBJECT HERE ***

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-u3.txt      |  21 +
 .../devicetree/bindings/usb/mt8173-xhci.txt        |  50 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts        |  15 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  31 +
 drivers/phy/Kconfig                                |   9 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-mt65xx-usb3.c                      | 426 +++++++++++
 drivers/usb/host/Kconfig                           |   9 +
 drivers/usb/host/Makefile                          |   4 +
 drivers/usb/host/xhci-mtk-sch.c                    | 436 +++++++++++
 drivers/usb/host/xhci-mtk.c                        | 836 +++++++++++++++++++++
 drivers/usb/host/xhci-mtk.h                        | 135 ++++
 drivers/usb/host/xhci-ring.c                       |  35 +-
 drivers/usb/host/xhci.c                            |  19 +-
 drivers/usb/host/xhci.h                            |   1 +
 15 files changed, 2021 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-u3.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty

In-Reply-To: 

(unknown),

[Mrs Christy Walton]

Greetings,

This is an official request for Professional/consultants who will stand as our regional representative to run logistics on behalf of zheng Group.We are looking for a payment collection agent in USA, Canada, Mexico and Europe. Salary is 10% of every payment you receive from our customers. Get back to us for more details if interested.

NOTE!!! it have no effect on your present job.


(1)Your Full names:
(2)Your Complete Address:
a. City:
b. State:
c. Zip code:
d. Country:
(3)Tele/cell numbers:
(4)Occupation:
(5)Gender:
(6)Age:
(7)Email:

Respectfully
Mr Tadashi Itoh (Human Resources)
zheng Group


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

(unknown),

[Mark Salter]

unsubscribe devicetree

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

(unknown),

[Zheng Group]

Greetings,

This is an official request for Professional/consultants who will stand 
as our regional representative to run logistics on behalf of zheng 
Group.We are looking for a payment collection agent in USA, Canada, 
Mexico and Europe. Salary is 10% of every payment you receive from our 
customers. Get back to us for more details if interested. contact us for more details.
 

NOTE!!! it have no effect on your present job.


Respectfully
Mr Tadashi Itoh (Human Resources)
zheng Group


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

(unknown),

[Asia Heritage Foundation]

ATTENTION

This is to inform you that you have been selected for this year fund donation please contact our online officer via email: asiaheritagefoundations-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 

for more information of claims.

From
Mr.Rehan Omar.
Secretary
Asia Heritage Foundation (AHF)
Italy Chapter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[wangwyy-hl91/bYNON7k1uMJSBkQmQ]

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

(unknown),

[Warner Losh]

Greetings,

I was looking at the draft link posted here
https://github.com/devicetree-org/devicetree-specification-released/blob/master/prerelease/devicetree-specification-v0.1-pre1-20160429.pdf
a while ago. I hope this is the right place to ask about it.

It raised a bit of a question. There's nothing in it talking about the
current
practice of using CPP to pre-process the .dts/.dtsi files before passing
them
into dtc to compile them into dtb.

Normally, I see such things outside the scope of standardization. However,
many of the .dts files that are in the wild today use a number of #define
constants to make things more readable (having GPIO_ACTIVE_HIGH
instead of '0' makes the .dts files easier to read). However, there's a
small
issue that I've had. The files that contain those definitions are currently
in the Linux kernel and have a wide variety of licenses (including none
at all).

So before even getting to the notion of licenses and such (which past
expereince suggests may be the worst place to start a discussion), I'm
wondering where that will be defined, and if these #defines will become
part of the standard for each of the bindings that are defined.

I'm also wondering where the larger issue of using cpp to process the dts
files will be discussed, since FreeBSD's BSDL dtc suffers interoperability
due to this issue. Having the formal spec will also be helpful for its care and
feeding since many fine points have had to be decided based on .dts
files in the wild rather than a clear spec.

Thanks again for spear-heading the effort to get a new version out now
that ePAPR has fallen on hard times.

Warner

P.S. I'm mostly a FreeBSD guy, but just spent some time digging into this
issue for another of the BSDs that's considering adopting DTS files.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Ryan]

 auth 74e10dbf subscribe devicetree ryanphilips19-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Maxime Ripard]

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges

Hi,

This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.

Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.

This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.

Let me know what you think,
Maxime

Changes from v4:
  - Removed unused functions

Changes from v3:
  - Depends on OF in Kconfig
  - Fixed typos in the driver comments
  - Removed the mention of a "passive" bridge in the bindings doc
  - Made the strcuture const
  - Removed the nops and best_encoders implementations
  - Removed the call to drm_bridge_enable in the sun4i driver

Changes from v2:
  - Changed the compatible as suggested
  - Rebased on top 4.8

Changes from v1:
  - Switch to using a vga-connector
  - Use drm_encoder bridge pointer instead of doing our own
  - Report the connector status as unknown instead of connected by
    default, and as connected only if we can retrieve the EDID.
  - Switch to of_i2c_get_adapter by node, and put the reference when done
  - Rebased on linux-next	      

Maxime Ripard (5):
  drm/sun4i: rgb: Remove the bridge enable/disable functions
  drm/bridge: Add RGB to VGA bridge support
  ARM: sun5i: a13-olinuxino: Enable VGA bridge
  ARM: multi_v7: enable VGA bridge
  ARM: sunxi: Enable VGA bridge

 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +++++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts          |  54 +++++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/sunxi_defconfig                   |   1 +
 drivers/gpu/drm/bridge/Kconfig                     |   7 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c                | 229 +++++++++++++++++++++
 drivers/gpu/drm/sun4i/sun4i_rgb.c                  |   6 -
 8 files changed, 341 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

(unknown),

[Mr Friedrich Mayrhofer]

Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer






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

(unknown),

[Mr Friedrich Mayrhofer]

Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for
more details.

Regards.
Friedrich Mayrhofer






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

(unknown),

[Mr Friedrich Mayrhofer]

Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer






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

(unknown),

[Qin's Yanjun]

How are you today and your family? I'm Qin Yanjun, Tak-lam, SBS, JP, and
Chief Executive of (HKMA). I have a concealed business suggestion for you,
It require your attention and honest co-operation.

Regards,
Mr. Qin Yanjun


______________________________

Sky Silk, http://aknet.kz

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

(unknown),

[nkosuta-f+iqBESB6gc]

[-- Attachment #1: EMAIL_05109557_devicetree.zip --]
[-- Type: application/zip, Size: 4727 bytes --]

(unknown),

[janepatrick00-VmEwxm1hRrAnxqbYAscKCQ]

Hello,
My name is Jane from UK, I came across you email address online, I will like to know more about you , I have a very important reason of contacting you which, I'll tell you in my next mail.
I wait for your reply
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Adrian Gillian Bayford]

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[nkosuta-f+iqBESB6gc]

[-- Attachment #1: $MONEY-52123352603-devicetree.zip --]
[-- Type: application/zip, Size: 2171 bytes --]

(unknown),

[Youichi Kanno]

Sir/Madam

I am sorry to encroach into your privacy in this manner, I found you  
listed in the Trade Center Chambers of Commerce directory here in  
Japan, My name is Youichi Kanno and I work in Audit & credit  
Supervisory role at The Norinchukin Bank, I need your assistance to  
process the fund claims oF $18,100,000.00 (Eighteen Million, One  
Hundred Thousand, USD) of a deceased client Mr. Grigor Kassan, And i  
need your assistance to process the fund claims, I only pray at this  
time that your address is still valid. I want to solicit your  
attention to receive this money on my behalf. The purpose of my  
contacting you is because my status would not permit me to do this  
alone.

I hope to hear from you soon so we can discuss the logistic of moving  
the funds to a safe offshore bank.

Yours sincerely,
Youichi Kanno
Phone Number: +81345400962





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

(unknown),

[nkosuta-f+iqBESB6gc]

[-- Attachment #1: 39579.zip --]
[-- Type: application/zip, Size: 3602 bytes --]

(unknown),

[Artur Lorincz]

Hello,

Could you please send me an update about this patch?

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

(unknown),

[Artur Lorincz]

Hello,

When you get to it, could you please send me an update about this patch?

I believe the attached (trivial) patch should take less time to review then reading this message.
 
Thanks,
Artur
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Artur Lorincz]

Hello,

Thanks for checking the patch.

I missed the #else part of he CONFIG_OF #ifdef previously.

I made the code properly depend on CONFIG_OF now.

I am not familiar with this code base. When time allows I would like to contribute by  refactoring code in this area.

Let me know if you have specific ideas about what should change and how the code should be refactored.

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

(unknown),

[Alfred Cheuk Chow]

Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.






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

(unknown),

[David Lechner]

Date: Sat, 23 Jun 2018 15:43:59 -0500
Subject: [PATCH 0/8] New remoteproc driver for TI PRU

This series adds a new remoteproc driver for the TI Programmable Runtime Unit
(PRU) that is present in some TI Sitara processors. This code has been tested
working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).

There are a couple of quirks that had to be worked around in order to get this
working. The PRU units have multiple memory maps. Notably, both the instruction
RAM and data RAM are at address 0x0. This caused the da_to_va callback to not
work because the same address could refer to two different locations. To work
around this, the first two patches add a "map" parameter to the da_to_va
callbacks so that we have an extra bit of information to make this distinction.

Also, on AM38xx we have to use pdata for accessing a reset since there is not
a reset controller. There are several other devices doing this, so the seems
the best way for now.

For anyone else who would like to test, I used the rpmsg-client-sample driver.
Just enable it in your kernel config. Then grab the appropriate firmware[1]
and put in in /lib/firmware/. Use sysfs to start and stop the PRU:

        echo start > /sys/class/remoteproc<n>/state
        echo stop > /sys/class/remoteproc<n>/state

[1]: firmware downloads:

AM18XX: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM18xx-PRU-rpmsg-client-sample.zip
AM335X: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM335x-PRU-rpmsg-client-sample.zip

David Lechner (8):
  remoteproc: add map parameter to da_to_va
  remoteproc: add page lookup for TI PRU to ELF loader
  ARM: OMAP2+: add pdata quirks for PRUSS reset
  dt-bindings: add bindings for TI PRU as remoteproc
  remoteproc: new driver for TI PRU
  ARM: davinci_all_defconfig: enable PRU remoteproc module
  ARM: dts: da850: add node for PRUSS
  ARM: dts: am33xx: add node for PRU remoteproc

 .../bindings/remoteproc/ti_pru_rproc.txt      |  51 ++
 MAINTAINERS                                   |   5 +
 arch/arm/boot/dts/am33xx.dtsi                 |   9 +
 arch/arm/boot/dts/da850.dtsi                  |   8 +
 arch/arm/configs/davinci_all_defconfig        |   2 +
 arch/arm/mach-omap2/pdata-quirks.c            |   9 +
 drivers/remoteproc/Kconfig                    |   7 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/imx_rproc.c                |   2 +-
 drivers/remoteproc/keystone_remoteproc.c      |   3 +-
 drivers/remoteproc/qcom_adsp_pil.c            |   2 +-
 drivers/remoteproc/qcom_q6v5_pil.c            |   2 +-
 drivers/remoteproc/qcom_wcnss.c               |   2 +-
 drivers/remoteproc/remoteproc_core.c          |  10 +-
 drivers/remoteproc/remoteproc_elf_loader.c    | 117 +++-
 drivers/remoteproc/remoteproc_internal.h      |   2 +-
 drivers/remoteproc/st_slim_rproc.c            |   2 +-
 drivers/remoteproc/ti_pru_rproc.c             | 660 ++++++++++++++++++
 drivers/remoteproc/wkup_m3_rproc.c            |   3 +-
 include/linux/platform_data/ti-pruss.h        |  18 +
 include/linux/remoteproc.h                    |   2 +-
 include/uapi/linux/elf-em.h                   |   1 +
 22 files changed, 899 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
 create mode 100644 drivers/remoteproc/ti_pru_rproc.c
 create mode 100644 include/linux/platform_data/ti-pruss.h

-- 
2.17.1