Re: [PATCH v7 0/5] Add mipi dsi support for rk3288

On 2016年01月06日 12:03, Chris Zhong wrote: The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller IP. This series adds support for a Synopsys DesignWare MIPI DSI host controller DRM driver. The MIPI DSI feature is tested on rk3288 evb board, backport them to chrome os kernel

Re: [PATCH] ARM64: tegra: Add support for Google Pixel C

rev4", "google,smaug-rev3", > + "google,smaug-rev1", "google,smaug", "nvidia,tegra210"; This looks a little funky. Is each revision a strict superset of the previous version? > + > + chosen { > + boota

Re: [PATCH 1/1] regulator: max8973: add support for junction thermal warning

On Wed, Jan 06, 2016 at 05:49:22PM +0530, Laxman Dewangan wrote: > On Wednesday 06 January 2016 05:48 PM, Mark Brown wrote: > >* PGP Signed by an unknown key > >On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote: > >> Enhanced transient response (ETR) will

Re: [PATCH v4 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

clock-output-names = "osc32k"; > + }; > + }; Just put the clocks under the root node. 'clocks' is not a special node. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] regulator: max8973: add support for junction thermal warning

On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote: > Enhanced transient response (ETR) will affect the configuration of CKADV. > +-maxim,junction-temp-warning: Junction temp warning on which device generates > + warning interrupts. This needs to specify what the values

Re: [PATCH 1/1] regulator: max8973: add support for junction thermal warning

On Wed, Jan 06, 2016 at 08:25:21AM -0600, Rob Herring wrote: > On Wed, Jan 06, 2016 at 12:37:35PM +0000, Mark Brown wrote: > > > I tried to roundoff to the next higher threshold when supported value (120 > > > or 140 degC) is not provided in driver. But it is

Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

On Tue, Jan 05, 2016 at 10:50:42AM +0530, Vignesh R wrote: > Hi Brian, > > On 12/11/2015 09:39 AM, Vignesh R wrote: > > Changes since v4: > > Use syscon to access system control module register in ti-qspi driver. > > > > Gentle ping... > Are you ok with MTD side changes of this patch series?

Re: [PATCH v2 2/3] drm/rockchip: vop: add rk3229 vop support

On 2016年01月05日 11:58, Yakir Yang wrote: RK3229 registers layout is simalar to RK3288 layout, only the interruput registers is different to RK3288. RK3229 support two overlay plane and one hwc plane, max output resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's. Signed-off-by:

Re: [PATCH] ASoC: cs35l32: avoid uninitialized variable access

On Mon, Jan 04, 2016 at 04:17:47PM +0100, Arnd Bergmann wrote: > On Saturday 02 January 2016 14:17:46 Mark Brown wrote: > > This would be a lot nicer if there was an __always_null annotation we > > could put on of_node for !OF configurations, that'd Just Work and this > > c

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote: > I understand, thanks for pointing this out. Well, for my use case, there > is no use in disabling the chip at any point as it powers the external > mmc. Presumably someone might decide not to use the MMC in some case (perhaps

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote: > Le mercredi 30 décembre 2015 à 16:33 +0000, Mark Brown a écrit : > > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote: > > > In my opinion, it would be more elegant to adapt the core regulat

Re: [PATCH 4/4] Document: spi: Add bindings for mediatek MT2701 soc platform

On Thu, Dec 31, 2015 at 10:59:03AM +0800, Leilk Liu wrote: > This patch adds a DT binding documentation for the MT2701 soc. > Please use subject lines reflecting the style for the subsystem. signature.asc Description: PGP signature

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote: > In my opinion, it would be more elegant to adapt the core regulator > framework to first enable the GPIO and then call the regulator enable > ops callback instead of handling the GPIO in the driver. Why would we want to

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Thu, Dec 24, 2015 at 07:12:53PM +0100, Paul Kocialkowski wrote: > Le mercredi 23 décembre 2015 à 11:56 +0000, Mark Brown a écrit : > > This isn't really adding support for the enable GPIO as the changelog > > suggests, it's requesting but not managing the GPIO. Since there is &

Re: next-20151222 build: 3 failures 13 warnings (next-20151222)

On Tue, Dec 22, 2015 at 09:46:36PM -0600, Andy Gross wrote: > On Tue, Dec 22, 2015 at 12:22:28PM +0000, Mark Brown wrote: > > which are caused by ab4256cfeab91569 (pinctrl: qcom: pmic-gpio/mpp: > > of_irq_count() == npins) which adds uses of irq_of_count() but that is > >

Re: [PATCH 3/6] ASoC: da7219: Update REFERENCES reg default, in-line with HW

On Wed, Dec 23, 2015 at 09:47:23AM +, Opensource [Adam Thomson] wrote: > On December 23, 2015 00:10, Mark Brown wrote: > > This is the sort of thing where a register patch would normally be used > > - if you put in a register patch for the older silicon then the driver

Re: [PATCH 3/6] regulator: lp872x: Remove warning about invalid DVS GPIO

On Wed, Dec 23, 2015 at 11:58:36AM +0100, Paul Kocialkowski wrote: > Some devices don't hook the DVS pin to a GPIO but to ground or VCC. > In those cases, it is not a problem to have no DVS GPIO. I would expect the driver at least needs to know how the pins or strapped, or otherwise have

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote: > + gpio = lp->pdata->enable_gpio; > + if (!gpio_is_valid(gpio)) > + return 0; > + > + /* Always set enable GPIO high. */ > + ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X >

Re: [PATCH 3/6] regulator: lp872x: Remove warning about invalid DVS GPIO

On Wed, Dec 23, 2015 at 12:50:20PM +0100, Paul Kocialkowski wrote: > Le mercredi 23 décembre 2015 à 11:41 +0000, Mark Brown a écrit : > > I would expect the driver at least needs to know how the pins or > > strapped, or otherwise have configuration for ignoring the input

Re: [PATCH 3/6] ASoC: da7219: Update REFERENCES reg default, in-line with HW

On Tue, Dec 22, 2015 at 06:27:53PM +, Adam Thomson wrote: > In current AB silicon, BIAS_EN field is enabled by default in the > REFERENCES register, so the regmap default value should reflect > this. This is the sort of thing where a register patch would normally be used - if you put in a

Re: [RESEND PATCH v2 2/2] ASoC: atmel-classd: DT binding for PDMIC driver

On Tue, Dec 22, 2015 at 12:37:24PM -0600, Rob Herring wrote: > On Sat, Dec 19, 2015 at 5:30 AM, Mark Brown <broo...@kernel.org> wrote: > >> "label" can be used here if this is really needed. > > The plastics for the system are often very important for audio >

Re: [PATCH v2 2/2] dt-bindings: sound: add devicetree document for rt5616

On Tue, Dec 22, 2015 at 01:45:03PM +0800, Caesar Wang wrote: > Add the description for rt5616 codec. Please use subject lines matching the style for the subsystem. signature.asc Description: PGP signature

[PATCH] of/irq: Export of_irq_count()

Some of the Qualcomm pinctrl drivers have started trying to use of_irq_count() in modular code but this fails to build as the symbol is not exported. Since there doesn't seem to be any reason not to export the symbol make it available to modules. Signed-off-by: Mark Brown <broo...@kernel.

Re: next-20151222 build: 3 failures 13 warnings (next-20151222)

On Tue, Dec 22, 2015 at 08:57:20AM +, Build bot for Mark Brown wrote: Today's linux-next fails to link an arm64 allmodconfig due to: > ERROR: "of_irq_count" [drivers/pinctrl/qcom/pinctrl-ssbi-mpp.ko] undefined! > ERROR: "of_irq_count" [drivers/pinctrl/qcom/pinct

Re: [RFC PATCH v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

Hi Yakir I want to convert drm/rockchip to support atomic api, I'd like you can do some modify to adapt it. - Mark On 2015年11月11日 15:45, Yakir Yang wrote: Hi guys: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant

Re: [RFC PATCH v1 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

On 2015年11月11日 15:46, Yakir Yang wrote: + hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD; + + drm_connector_helper_add(>connector, +_hdmi_connector_helper_funcs); + drm_connector_init(drm, >connector, _hdmi_connector_funcs, +

Re: [PATCH 12/12] ASoC: rsnd: add Multi channel support

On Fri, Dec 18, 2015 at 02:04:51PM -0600, Rob Herring wrote: > On Thu, Dec 17, 2015 at 03:00:10AM +, Kuninori Morimoto wrote: > > Signed-off-by: Kuninori Morimoto > > --- > > .../devicetree/bindings/sound/renesas,rsnd.txt | 18 > For the binding:

Re: [RESEND PATCH v2 2/2] ASoC: atmel-classd: DT binding for PDMIC driver

On Fri, Dec 18, 2015 at 01:56:21PM -0600, Rob Herring wrote: > On Thu, Dec 17, 2015 at 05:50:00PM +0800, Songjun Wu wrote: > > +- atmel,model > > + The user-visible name of this sound card. > > + The default value is "PDMIC". > When and why would this be different than the default? >

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

to be described, and require this property to be present. * Update the driver to account for that and the compatible string change. * Send a complete PATCHv8 (or PATCHv$X where X > 7) series with a proper changelog. Thanks, Mark. [1] http://lists.infradead.org/pipermail/li

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote: > Hi Mark, > > On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > >> +- distance-matrix > >> + This property defines a matrix to describe the relative distanc

Re: [PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

Hi, On Fri, Dec 11, 2015 at 08:11:07PM +0530, Ganapatrao Kulkarni wrote: > On Fri, Dec 11, 2015 at 7:23 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > > Hi, > > > > On Tue, Nov 17, 2015 at 10:50:41PM +0530, Ganapatrao Kulkarni wrote: > >> DT bindings for n

Re: [PATCH v2 2/2] Documentation: dt-bindings: Add option to workaround STE.VALID in Broadcom Vulcan

ot; mode. Enabling this, > > + populates needed bits. > > This should really describe more about what happens, I think. For example, > > "Enable ATS and Stage-2 AArch64 translation in bypass STEs, since some > hardware requires this in order for an STE to be

Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec

On Wed, Dec 16, 2015 at 01:54:20PM +, Måns Rullgård wrote: > Mark Brown <broo...@kernel.org> writes: > > I need the patch in a form I can apply. > I assumed your email client had some way of displaying the message I > replied to. Guess I was wrong. My workflow for r

[PATCH 6/6] dt-bindings: add document for rk3036-vop

Cc: Rob Herring <robh...@kernel.org> Cc: Pawel Moll <pawel.m...@arm.com> Cc: Mark Rutland <mark.rutl...@arm.com> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> Cc: Kumar Gala <ga...@codeaurora.org> Cc: devicetree@vger.kernel.org Signed-off-by: Mar

Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec

On Wed, Dec 16, 2015 at 01:31:30PM +, Måns Rullgård wrote: > This is the 1/1 you were missing. I need the patch in a form I can apply. > Am I the only one who is annoyed by scripts/get_maintainer.pl not > returning all the addresses it should in cases like this? Is there some > trick I'm

Re: [PATCH v4 1/3] dt-binding: power: Add otg regulator binding

On Wed, Dec 16, 2015 at 12:13:50AM +0100, Sebastian Reichel wrote: > On Tue, Dec 15, 2015 at 11:52:10AM -0800, Tim Bird wrote: > > Add a binding for the regulator which controls the OTG chargepath switch. > > The OTG switch gets its power from pm8941_5vs1, and that should be > > expressed as a

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 04:23:18PM +, Catalin Marinas wrote: > On Tue, Dec 15, 2015 at 03:57:37PM +0000, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 03:46:51PM +, Juri Lelli wrote: > > > On 15/12/15 15:32, Mark Rutland wrote: > > > > On Tue, Dec 15, 2015 a

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 05:59:34PM +0100, Vincent Guittot wrote: > On 15 December 2015 at 17:41, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Tue, Dec 15, 2015 at 04:23:18PM +, Catalin Marinas wrote: > >> On Tue, Dec 15, 2015 at 03:57:37PM +, Mark Rutland wrot

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 03:32:19PM +, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote: > > On Tue, Dec 15, 2015 at 02:01:36PM +0000, Mark Rutland wrote: > > > I really don't want to see a table of magic numbers in the kernel. > >

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 05:45:16PM +, Mark Brown wrote: > On Tue, Dec 15, 2015 at 05:28:37PM +0000, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 05:17:13PM +0000, Mark Brown wrote: > > > > Obviously people are going to get upset if we introduce performance > >

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 06:10:03PM +, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 05:45:16PM +0000, Mark Brown wrote: > > > I'm not sure I follow w.r.t. "inherently less information", unless you > > > mean trying to debug without access to that DTB? >

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 05:28:37PM +, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 05:17:13PM +0000, Mark Brown wrote: > > Obviously people are going to get upset if we introduce performance > > regressions - but that's true always, we can also introduce problems > > wit

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 05:17:13PM +, Mark Brown wrote: > On Tue, Dec 15, 2015 at 03:32:19PM +0000, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote: > > > On Tue, Dec 15, 2015 at 02:01:36PM +, Mark Rutland wrote: > > > >

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 06:47:20PM +0100, Vincent Guittot wrote: > On 15 December 2015 at 18:15, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Tue, Dec 15, 2015 at 05:59:34PM +0100, Vincent Guittot wrote: > >> On 15 December 2015 at 17:41, Mark Rutland <

Re: [PATCH] arm64: perf: Correct Cortex-A53/A57 compatible values

On Tue, Dec 15, 2015 at 09:33:20AM +0100, Geert Uytterhoeven wrote: > Use commas instead of periods. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Acked-by: Mark Rutland <mark.rutl...@arm.com> Mark. > --- > Documentation/devicetree/bindings/arm

Re: [PATCH v2] ARM: psci: Fix indentation in DT bindings

On Tue, Dec 15, 2015 at 10:55:59AM +0100, Geert Uytterhoeven wrote: > Fix bogus indentation of the PSCI compatible values, reformat. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > Acked-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> That looks muc

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 03:46:51PM +, Juri Lelli wrote: > On 15/12/15 15:32, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote: > > > My expectation is that we just need good enough, not perfect, and that > > > seems to matc

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 12:22:38PM +, Juri Lelli wrote: > I'm proposing to add a new value because I couldn't find any proxies in > the current bindings that bring us any close to what we need. If I > failed in looking for them, and they actually exists, I'll personally be > more then happy

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 01:39:51PM +, Mark Brown wrote: > On Tue, Dec 15, 2015 at 12:22:38PM +, Juri Lelli wrote: > > > So then why isn't it adequate to just have things like the core types in > > > there and work from there? Are we really expecting the tuning to be

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 02:24:58PM +, Juri Lelli wrote: > Hi Mark, Hi Juri, > On 15/12/15 14:01, Mark Rutland wrote: > > I really don't want to see a table of magic numbers in the kernel. > > Doesn't seem to be a clean and scalable solution to me either. It is not > eas

Re: [PATCH] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes

t; > > + compatible = "arm,cortex-a53-pmu"; > > > > > > > Should this list both? > > IMHO, we don't need to list both. The pmu binding document also says: > "compatible : should be one of " > > Dear Mark, > &g

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 02:01:36PM +, Mark Rutland wrote: > I really don't want to see a table of magic numbers in the kernel. Right, there's pitfalls there too although not being part of an ABI does make them more manageable. One thing it's probably helpful to establish here is how m

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Tue, Dec 15, 2015 at 03:08:13PM +, Mark Brown wrote: > On Tue, Dec 15, 2015 at 02:01:36PM +0000, Mark Rutland wrote: > > > I really don't want to see a table of magic numbers in the kernel. > > Right, there's pitfalls there too although not being part of an ABI >

Re: [PATCH v3] spi: dts: sun4i: Add support for hardware-based wait time between words

On Mon, Dec 14, 2015 at 12:23:29AM +0100, Marcus Weseloh wrote: > Should I resend the patch? No, it's OK. signature.asc Description: PGP signature

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Mon, Dec 14, 2015 at 12:36:16PM +, Juri Lelli wrote: > On 11/12/15 17:49, Mark Brown wrote: > > The purpose of the capacity values is to influence the scheduler > > behaviour and hence performance. Without a concrete definition they're > > just magic numbers whi

Re: [PATCH] ARM64: ZynqMP: DT: Fix GIC's 'reg' property

reg = <0x0 0xf901 0x1000>, > + <0x0 0xf902 0x2>, > <0x0 0xf904 0x2>, > - <0x0 0xf906f000 0x2000>; > + <0x0 0xf906 0x2>;

Re: [PATCH v3] spi: dts: sun4i: Add support for hardware-based wait time between words

On Mon, Dec 14, 2015 at 12:04:11AM +0100, Marcus Weseloh wrote: > Adds a new property "spi-word-wait-ns" to the spi-bus binding that allows Please don't bury patches in reply to existing serieses, it makes it hard to follow what's going on with regard to which versions are current and so on.

Re: [PATCH v2 2/4] ASoC: sun4i-codec: Add support for PA gpio pin

On Fri, Dec 11, 2015 at 07:43:57PM +0100, Hans de Goede wrote: > + gpiod_set_value_cansleep(scodec->gpio_pa, > + !!SND_SOC_DAPM_EVENT_ON(event)); Why the double negation here? The macro is already supposed to give you a boolean and

Re: [PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

0 -> 2 = 40 > + 1 -> 3 = 40 How is this scaled relative to a local access? Do we assume that a local access has value 1, e.g. each hop takes 20x a local access in this example? Do we need a finer-grained scale (e.g. to allow us to represent a distance of 2.5)? The ACPI SLIT spec seems to give local accesses a value 10 implicitly to this end. Other than those points, I'm happy with this binding. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 8/8] arm64: add sysfs cpu_capacity attribute

On Thu, Dec 10, 2015 at 06:01:59PM +, Juri Lelli wrote: > On 10/12/15 15:59, Mark Brown wrote: > > On Thu, Dec 10, 2015 at 02:15:04PM +, Dietmar Eggemann wrote: > > > On 23/11/15 14:28, Juri Lelli wrote: > > > > The new attribute shows up as: > &

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Thu, Dec 10, 2015 at 05:58:20PM +, Juri Lelli wrote: > On 10/12/15 15:30, Mark Brown wrote: > > On Mon, Nov 23, 2015 at 08:06:31PM -0600, Rob Herring wrote: > > > In other words, I want to see these numbers have a defined method > > > of determining them a

Re: [RFC PATCH 8/8] arm64: add sysfs cpu_capacity attribute

On Thu, Dec 10, 2015 at 02:15:04PM +, Dietmar Eggemann wrote: > On 23/11/15 14:28, Juri Lelli wrote: > > The new attribute shows up as: > > /sys/devices/system/cpu/cpu*/cpu_capacity > This sysfs interface is not really needed for arm or arm64. People can > build the dt blob if they want to

Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding

On Wed, Dec 09, 2015 at 11:20:45PM +0100, Sebastian Reichel wrote: > On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote: > > There are other switches in the charger block that are not > > exposed yet. This one handles the the OTG (vbus) charge pathway. > > Others handle other charge

Re: [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT

ect of? It sounds like we should be describing that. We should at least have a better definition of what this means we must avoid. Thanks Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

On Mon, Nov 23, 2015 at 08:06:31PM -0600, Rob Herring wrote: > I think you need something absolute and probably per MHz (like > dynamic-power-coefficient property). Perhaps the IPC (instructions per > clock) value? > In other words, I want to see these numbers have a defined method > of

Re: [PATCH v2 6/6] arm64: renesas: r8a7795: Add L2 cache-controller nodes

ed that the cache geometry could be derived from architected registers used for set/way maintenance. However, we knew that this did not describe how those caches were linked to each other (e.g. which CPU shared with level x cache). So the description in DT was required to provide that. Now, we a

Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding

On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote: > On 12/09/2015 06:36 AM, Rob Herring wrote: > > You need a regulator-name property. Also, should should define valid > > values for regulator-min-microvolt and regulator-max-microvolt. > All of those are listed as optional properties in

Re: [PATCH V3 2/2] ASoC: img: Add driver for Pistachio internal DAC

On Wed, Dec 09, 2015 at 04:30:09PM +, Damien Horsley wrote: > +static const struct snd_kcontrol_new pistachio_internal_dac_snd_controls[] = > { > + SOC_SINGLE("Mute Switch", PISTACHIO_INTERNAL_DAC_CTRL, 2, 1, 0) > +}; This would normally be called "Playback Switch" and (presumably) have

Re: [PATCH V2 2/2] ASoC: img: Add driver for Pistachio internal DAC

On Tue, Dec 08, 2015 at 05:05:24PM +, Damien Horsley wrote: > +static int pistachio_internal_dac_set_mute(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol); > +

Re: [PATCH v2 6/6] arm64: renesas: r8a7795: Add L2 cache-controller nodes

On Tue, Dec 08, 2015 at 07:50:38PM +0100, Dirk Behme wrote: > On 07.12.2015 20:03, Mark Rutland wrote: > >On Mon, Dec 07, 2015 at 06:49:43PM +, Sudeep Holla wrote: > >> > >>On 07/12/15 18:24, Geert Uytterhoeven wrote: > >>>+ L2_CA57: cache-controller@

Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support

On Mon, Dec 07, 2015 at 01:58:47PM -0600, Andrew F. Davis wrote: > As all of this driver should be taken though the MFD tree how > can this gpiolib change be handled? If we have gpio.parent it > will not build on MFD, with gpio.dev it will fail to build when > the changes are merged from the gpio

Re: [PATCH v2 6/6] arm64: renesas: r8a7795: Add L2 cache-controller nodes

which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds. I don't see that these are necessary at all. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Fri, Dec 04, 2015 at 12:26:58PM -, Simon Arlott wrote: > On Fri, December 4, 2015 11:00, Mark Brown wrote: > > OK, so the power domains should be being represented and managed as such > > rather than using regulators - it's a better fit (doing things like > > s

Re: [PATCH] spi: sh-msiof: Add support for SH-Mobile AG5

On Fri, Dec 04, 2015 at 12:56:08PM -0600, Rob Herring wrote: > On Mon, Nov 30, 2015 at 03:14:00PM +0100, Geert Uytterhoeven wrote: > > MSIOF in SH-Mobile AG5 (sh73a0) is handled fine by the existing driver. > > Signed-off-by: Geert Uytterhoeven > Applied, thanks. I've

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Thu, Dec 03, 2015 at 11:51:16PM +, Simon Arlott wrote: > On 03/12/15 23:45, Mark Brown wrote: > > Are you *sure* these are regulators and not power domains? These names > > look a lot like they could be power domains. > No, I'm not sure. Some of them are may actu

Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings

On Fri, Dec 04, 2015 at 10:10:04AM +0900, Krzysztof Kozlowski wrote: > The regulator/s5m8767-regulator.txt duplicates some of the information > about bindings with old mfd/s2mps11.txt. Now common part exists entirely > in mfd/samsung,sec-core.txt so: Acked-by: Mark Brown <broo..

Re: [PATCH 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

; everything could be organized in a more readable way. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature

Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support

On Tue, Nov 24, 2015 at 04:26:24PM +, Lee Jones wrote: > On Wed, 18 Nov 2015, Andrew F. Davis wrote: > > Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++ > > drivers/gpio/Kconfig | 2 +- > > drivers/gpio/gpio-tps65912.c | 317

Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

On Fri, Dec 04, 2015 at 10:10:05AM +0900, Krzysztof Kozlowski wrote: > The mfd/s2mpa01.txt duplicates some of the information about bindings > with old mfd/s2mps11.txt. Now common part exists entirely in > mfd/samsung,sec-core.txt so: Acked-by: Mark Brown <broo...@kernel.org> &

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Thu, Dec 03, 2015 at 08:14:33AM +, Simon Arlott wrote: > On 03/12/15 00:06, Mark Brown wrote: > > this it should know at least something about how to control the device > > from the compatible string. If you're making a generic driver it should > > not make referenc

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Thu, Dec 03, 2015 at 11:38:28PM +, Simon Arlott wrote: > #define MISC_IDDQ_CTRL_GMAC (1<<18) > #define MISC_IDDQ_CTRL_WLAN_PADS(1<<13) > #define MISC_IDDQ_CTRL_PCIE (1<<12) > #define MISC_IDDQ_CTRL_FAP (1<<11) > #define MISC_IDDQ_CTRL_VDSL_MIPS(1<<10) >

Re: [PATCH v4 1/5] spi: introduce accelerated read support for spi flash devices

On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote: > In addition to providing direct access to SPI bus, some spi controller > hardwares (like ti-qspi) provide special port (like memory mapped port) > that are optimized to improve SPI flash read performance. I'm reasonably OK with this

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Wed, Dec 02, 2015 at 08:26:36PM +, Simon Arlott wrote: > On 02/12/15 12:53, Mark Brown wrote: > > This is the sort of thing you can pick up from the SoC compatible > > strings. As things stand there is zero content in this driver that > > relates to this SoC. &

Re: [PATCH v4 2/3] ASoC: cygnus: Add Cygnus audio DAI driver

On Tue, Dec 01, 2015 at 06:17:54PM -0800, Simran Rai wrote: > On 11/22/2015 5:44 AM, Mark Brown wrote: > >I would expect any initialisationn of clocks beyond the ones that the > >device directly interacts with to be handled within the clock API > >configuration rather than

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Wed, Dec 02, 2015 at 12:45:50PM -, Simon Arlott wrote: > On Tue, December 1, 2015 22:16, Mark Brown wrote: > > Why are these in the DT, I would expect that if this is a driver for a > > specific SoC all these properties would be known as a result of that. > This is a d

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

On Mon, Nov 30, 2015 at 08:30:07PM +, Simon Arlott wrote: > +- offset: register offset > +- mask: register enable mask > +- startup-delay-us: startup time in microseconds Why are these in the DT, I would expect that if this is a driver for a specific SoC all these properties would be known

Re: [alsa-devel] [PATCH 2/2] ASoC: pcm3168a: Add driver for pcm3168a codec

On Mon, Nov 30, 2015 at 04:49:30PM +, Damien Horsley wrote: > On 27/11/15 12:54, Mark Brown wrote: > > Please try to keep your CC lists reasonable - only CC people who have an > > interest in the patch you're posting. The CC list you have here is far > > too broad, I

Re: [PATCH 1/2] regulator: Add coupled regulator

hat's actually a very good question, and I don't have a good answer > to it. I guess the safest approach would be to roll back and do the > opposite operation on the one we previously enabled / disabled. > I wonder whether it might damage the hardware or not though. > Mark? Yeah, I'

Re: [PATCH (v2) 2/2] regulator: bcm63xx: Add BCM63xx fixed regulator device

On Mon, Nov 30, 2015 at 08:38:30PM +, Simon Arlott wrote: > The BCM63xx has one or more registers with bits that act as regulators > to enable/disable power to individual chip peripherals. Please don't submit new revisions of single patches in followup to an existing series, it just makes

Re: [PATCH 1/2] regulator: Add coupled regulator

On Mon, Nov 30, 2015 at 04:29:05PM +0100, Maxime Ripard wrote: > +static struct of_device_id coupled_regulator_of_match[] = { > + { .compatible = "coupled-voltage-regulator" }, > + { /* Sentinel */ }, > +}; This defines a device tree binding but does not document it - doucmentation is

Re: [PATCH 1/2] regulator: Add regmap support to regulator-fixed device tree binding

On Sat, Nov 28, 2015 at 09:13:01PM +, Simon Arlott wrote: > Add properties for regmap to the regulator-fixed device tree binding: > * Reference the regmap phandle > * Specify the enable offset and enable mask > * Reuse enable-active-high for regmap > > This is required for Broadcom BCM63xx

Re: [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote: > This binding describes LM3631 and LM3632 regulator properties. Please use subject lines matching the style for the subsystem. signature.asc Description: PGP signature

Re: [alsa-devel] [PATCH 2/2] ASoC: pcm3168a: Add driver for pcm3168a codec

On Tue, Nov 24, 2015 at 02:43:44PM +, Damien Horsley wrote: > From: "Damien.Horsley" > > Add driver for Texas Instruments pcm3168a codec Please try to keep your CC lists reasonable - only CC people who have an interest in the patch you're posting. The CC list you

Re: Dynamically adding SPI buses (was: Re: [PATCH v8 0/8] Device Tree Overlays - 8th time's the charm)

On Fri, Nov 27, 2015 at 02:06:41PM +0100, Geert Uytterhoeven wrote: > (replaying to an old mail, as I'm seeing the exact same behavior with current > overlay code) I don't seem to have this mail... I'm not even sure that mailing list archive does (at least

Re: [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

On Fri, Nov 27, 2015 at 02:44:50PM -0600, Rob Herring wrote: > On Fri, Nov 27, 2015 at 12:37:50PM +0000, Mark Brown wrote: > > On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote: > > > This binding describes LM3631 and LM3632 regulator properties. > > Please us

Re: Preprocessor arithmetic in dtsi files (base + offset)

tic should be avoided. > twd-timer@XXX { > compatible = "arm,cortex-a9-twd-timer"; > reg = <SCU_BASE+0x600 0x10>; > > Are the @XXX important? Can they be removed altogether? The bit after the @ is called the unit-address. It's mean

Re: [PATCH] ASoC: Atmel: ClassD: add GCK's parent clock in DT binding

On Wed, Nov 25, 2015 at 05:45:24PM -0600, Rob Herring wrote: > On Mon, Nov 23, 2015 at 05:19:58PM +0800, Songjun Wu wrote: > > Set GCK's parent as audio clock. > > Signed-off-by: Songjun Wu > Applied, thanks. I already applied this to the ASoC tree. signature.asc

Re: [PATCH v3 2/4] devicetree: bindings: let thermal-sensor point to other thermal zones

; > Cc: Rob Herring <robh...@kernel.org> > Cc: Pawel Moll <pawel.m...@arm.com> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> > Cc: Kumar Gala <ga...@codeaurora.org> > Cc: devicetree@vger.kernel.org &

Re: [alsa-devel] [PATCH 0/2] Add support for Pistachio internal DAC

On Mon, Nov 23, 2015 at 05:24:57PM +, Damien Horsley wrote: > From: "Damien.Horsley" > > Add binding document and driver for Pistachio internal DAC Please don't add noise like [alsa-devel] to the subject line of mails, it just consumes space in the subject line

Re: [alsa-devel] [PATCH 2/2] ASoC: img: Add driver for Pistachio internal DAC

On Mon, Nov 23, 2015 at 05:24:59PM +, Damien Horsley wrote: > + /* The mute state as set by alsa using the digital_mute callback */ > + bool alsa_mute_state; > + /* The mute state as set by the userspace mute control */ > + bool control_mute_state; > + /* The actual mute

  1   2   3   4   5   6   7   8   9   10   >