Hi Simon,
On Fri, Nov 13, 2015 at 1:28 AM, Simon Horman wrote:
> On Thu, Nov 12, 2015 at 11:03:33AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Nov 12, 2015 at 2:15 AM, Simon Horman wrote:
>> > On Tue, Nov 10, 2015 at 09:35:06AM +0100, Geert Uytterhoeven wrote:
>> >> As of commits 5cfdedb7b9a0fe
On Wed, 2015-11-11 at 13:41 -0800, Brian Norris wrote:
> One more small comment, since you're respinning this:
>
> On Fri, Nov 06, 2015 at 11:48:08PM +0800, Bayi Cheng wrote:
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
> > b/drivers/mtd/spi-nor/mtk-quadspi.c
> > new file mode 100644
> > in
On Wed, 2015-11-11 at 12:38 -0800, Brian Norris wrote:
> On Fri, Nov 06, 2015 at 11:48:07PM +0800, Bayi Cheng wrote:
> > Add device tree binding documentation for serial flash with
> > Mediatek serial flash controller
> >
> > Signed-off-by: Bayi Cheng
> > ---
>
> Applied to l2-mtd.git/next (for
On 2015年11月12日 16:40, Heiko Stuebner wrote:
> Am Donnerstag, 12. November 2015, 09:13:20 schrieb Zain:
>> On 2015年11月12日 07:57, Heiko Stuebner wrote:
>>> Am Mittwoch, 11. November 2015, 14:35:57 schrieb Zain Wang:
Set an ID for crypto clk, so that it can be called in other part.
Si
On Wed, 2015-11-11 at 12:26 -0800, Brian Norris wrote:
> On Wed, Nov 11, 2015 at 10:04:14PM +0800, Bayi Cheng wrote:
> > On Mon, 2015-11-09 at 18:46 -0800, Brian Norris wrote:
> > > I believe you didn't completely answer all my questions from v5 though.
> > > I'll repeat a bit here. Particularly, r
On 2015年11月12日 20:32, Heiko Stuebner wrote:
> Hi Zain,
>
> I was able to sucessfully test your crypto-driver, but have found some
> improvements below that should probably get looked at:
>
> Am Mittwoch, 11. November 2015, 14:35:58 schrieb Zain Wang:
>> Crypto driver support:
>> ecb(aes) cbc
On 10-11-15, 11:20, Javi Merino wrote:
> The way they are described here is useful only for this platform, but
> it's not generic. It only takes into account voltage as (I assume)
> it's the only variable that affects it in this implementation. A
> generalized version of the static power should t
On 09-11-15, 17:29, Punit Agrawal wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the exi
On Fri, Nov 13, 2015 at 12:04 PM, Chen-Yu Tsai wrote:
> A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. It's
> regulators provide power to various parts of the SoC and the board.
>
> Also add simplefb regulator supplies and update existing ones.
>
> Signed-off-by: Chen-Yu Tsai
On Fri, Nov 13, 2015 at 12:04 PM, Chen-Yu Tsai wrote:
> axp20x support has been split into 2 parts, I2C and RSB interface
> variants.
>
> Update the MFD_AXP20X symbol for I2C support, and also enable
> MFD_AXP20X_RSB to support RSB variants. Build these drivers as
> modules.
>
> Keep MFD_AXP20X en
The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".
This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue laye
This board has a X-Powers AXP223 PMIC connected via RSB. It's regulators
provide power to various parts of the SoC and the board.
Also update the regulator supply phandles.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 79 +-
1 file cha
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 11 ++
drivers/mfd/Makefile
axp20x support has been split into 2 parts, I2C and RSB interface
variants.
Update the MFD_AXP20X symbol for I2C support, and also enable
MFD_AXP20X_RSB to support RSB variants. Build these drivers as
modules.
Keep MFD_AXP20X enabled for now, to ease migration for automated
boot farms while the p
Some boards, such as tablets, have regulators providing power to parts
of the display pipeline, like signal converters and LCD panels.
Add labels to the simplefb device nodes so that we can reference them
in the board dts files to add regulator supply properties.
Signed-off-by: Chen-Yu Tsai
---
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Mark Brown
---
drivers/regulator/axp20x-regulator.c | 3
axp20x support has been split into 2 parts, I2C and RSB interface
variants.
Update the MFD_AXP20X symbol for I2C support, and also enable
MFD_AXP20X_RSB to support RSB variants.
Keep MFD_AXP20X enabled for now, to ease migration for automated boot
farms while the patches are being merged. This sh
A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. It's
regulators provide power to various parts of the SoC and the board.
Also add simplefb regulator supplies and update existing ones.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 84
axp20x support has been split into 2 parts, I2C and RSB interface
variants.
Update the MFD_AXP20X symbol for I2C support. Also enable SUNXI_RSB
MFD_AXP20X_RSB to support RSB variants. Build these drivers as
modules.
Keep MFD_AXP20X enabled for now, to ease migration for automated
boot farms while
A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. It's
regulators provide power to various parts of the SoC and the board.
Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
---
Documentation/devicetree/bindings/mfd/ax
Hi everyone,
This is v2 of the AXP223 PMIC series.
Changes since v1:
- Dropped NMI interrupt controller dts patch (Merged)
- Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE
- Keep the axp20x core bits named axp20x.c
- Add patch 7 to add AXP223 to sun8i-q8-co
On Thu, Nov 12, 2015 at 4:42 AM, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote:
>> On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote:
>> > Cc: Rob Herring
>> > Cc: Pawel Moll
>> > Cc: Mark Rutland
>> > Cc: Ian Campbell
>> > Cc: Kumar Gala
>> >
>> >
On Thu, Nov 12, 2015 at 3:42 PM, Peter Maydell wrote:
> On 12 November 2015 at 21:33, Rob Herring wrote:
>> On Thu, Nov 12, 2015 at 04:24:50PM +, Peter Maydell wrote:
>>> The existing device tree bindings assume that we are only trying to
>>> describe a single address space with a device tree
+devicetree-spec
On Thu, Nov 12, 2015 at 5:53 PM, Greg Hackmann wrote:
> ramoops is one of the remaining places where ARM vendors still rely on
> board-specific shims. Device Tree lets us replace those shims with
> generic code.
I've had a version this in my tree forever to push upstream...
>
On 11/12, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 6:11 PM, Stephen Boyd wrote:
> > On 11/12, Rob Herring wrote:
> >> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote:
> >> > On 11/12, Rob Herring wrote:
> >> >> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
> >>
> >> >> > +
This patch fixes explain the occasion of "hisilcon,mdio" according to
Arnd's comments. specify it is only used for hip04.
First, please give your commnents.
Signed-off-by: huangdaode
---
Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 4 +++-
1 file changed, 3 insertions(+), 1 de
On Thu, Nov 12, 2015 at 6:11 PM, Stephen Boyd wrote:
> On 11/12, Rob Herring wrote:
>> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote:
>> > On 11/12, Rob Herring wrote:
>> >> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
>>
>> >> > +Some qcom based bootloaders identify the dt
On Thu, Nov 12, 2015 at 11:03:33AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Nov 12, 2015 at 2:15 AM, Simon Horman wrote:
> > On Tue, Nov 10, 2015 at 09:35:06AM +0100, Geert Uytterhoeven wrote:
> >> As of commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
> >> dedi
On 11/12/2015 04:06 PM, Al Stone wrote:
On 11/05/2015 09:41 AM, Guenter Roeck wrote:
On 11/05/2015 07:00 AM, Fu Wei wrote:
Hi Timur,
On 5 November 2015 at 22:40, Timur Tabi wrote:
Fu Wei wrote:
Did you really read the "Note" above OK, let me paste it again
and again:
SBSA 2.3 Page
On Fri, 2015-11-13 at 11:08 +1100, Daniel Axtens wrote:
> Gavin Shan writes:
>
> > void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> > {
> > -> >> > pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> > +> >> > int option, freset = 0;
> > +
> > +> >> > if (dev->subordinate
On 11/12/2015 06:06 PM, Al Stone wrote:
If it is a NAK, that's fine, but I also want to be sure I understand what the
objections are. Based on my understanding of the discussion so far over the
multiple versions, I think the primary objection is that the use of pretimeout
makes this driver too c
Following some discussion on IRC, it looks like there are roughly 2
machines on the planet with skiboot and p5ioc2, so I'm not worried about
that any more.
I am still vaguely concerned about a failing fundamental reset.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe
On 11/12, Olof Johansson wrote:
> On Mon, Oct 26, 2015 at 2:25 PM, Stephen Boyd wrote:
> > +Examples:
> > +
> > + "qcom,msm8916-v1-cdp-pm8916-v2.1"
>
> This is just awkward, but this...
>
> > +
> > +A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of
> > version
> > +2
On Fri, Nov 13, 2015 at 11:08:29AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
>> {
>> -pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
>> +int option, freset = 0;
>> +
>> +if (dev->subordinate)
>> +pci_walk_bus(dev
On 11/12, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote:
> > On 11/12, Rob Herring wrote:
> >> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
>
> >> > +Some qcom based bootloaders identify the dtb blob based on a set of
> >> > +device properties like SoC,
Gavin Shan writes:
> void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> {
> - pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> + int option, freset = 0;
> +
> + if (dev->subordinate)
> + pci_walk_bus(dev->subordinate,
> + pnv_pci_dev_reset_type,
On Thu, Nov 12, 2015 at 3:53 PM, Greg Hackmann wrote:
> ramoops is one of the remaining places where ARM vendors still rely on
> board-specific shims. Device Tree lets us replace those shims with
> generic code.
>
> These bindings mirror the ramoops module parameters, with two small
> differences
On 11/05/2015 09:41 AM, Guenter Roeck wrote:
> On 11/05/2015 07:00 AM, Fu Wei wrote:
>> Hi Timur,
>>
>> On 5 November 2015 at 22:40, Timur Tabi wrote:
>>> Fu Wei wrote:
Did you really read the "Note" above OK, let me paste it again
and again:
SBSA 2.3 Page 23 :
>>>
Eddie Huang writes:
> On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote:
>> Hi Eddie,
>>
>> Kevin Hilman writes:
>>
>> > Eddie Huang writes:
>> >
>> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote:
>> >>> Hi Eddie,
>> >>>
>> >>> [...]
>> >>>
>> >>> > I check the log [0],
>> >>>
ramoops is one of the remaining places where ARM vendors still rely on
board-specific shims. Device Tree lets us replace those shims with
generic code.
These bindings mirror the ramoops module parameters, with two small
differences:
(1) dump_oops becomes an optional "no-dump-oops" property, sinc
On Thu, Nov 12, 2015 at 09:27:21AM +0800, Yakir Yang wrote:
> Hi Rob,
>
> On 11/12/2015 07:10 AM, Rob Herring wrote:
> >On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote:
> >>Some edp screen do not have hpd signal, so we can't just return
> >>failed when hpd plug in detect failed.
> >>
>
On Thu, Nov 12, 2015 at 10:53:59AM +0900, Simon Horman wrote:
> In general Renesas hardware is not documented to the extent where the
> relationship between IP blocks on different SoCs can be assumed although
> they may appear to operate the same way. Furthermore the documentation
> typically does
On Fri, Nov 13, 2015 at 09:59:27AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> When pnv_pci_reset_secondary_bus() is called to issue reset on
>> the indicated secondary bus, the bus can't be root bus. So we
>> needn't consider root bus in the function.
>
>It took me a while to convince my
Hi,
On Mon, Oct 26, 2015 at 2:25 PM, Stephen Boyd wrote:
> Some qcom based bootloaders identify the dtb blob based on a set
> of device properties like SoC, platform, PMIC, and revisions of
> those components. In downstream kernels, these values are added
> to the different component dtsi files (
On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote:
> On 11/12, Rob Herring wrote:
>> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
>> > Some qcom based bootloaders identify the dtb blob based on a set
>> > of device properties like SoC, platform, PMIC, and revisions of
>> > those
Gavin Shan writes:
> When pnv_pci_reset_secondary_bus() is called to issue reset on
> the indicated secondary bus, the bus can't be root bus. So we
> needn't consider root bus in the function.
It took me a while to convince myself that this is correct. For the
record, this is why it's correct:
Hi Eduardo,
Am Donnerstag, 12. November 2015, 10:29:52 schrieb Eduardo Valentin:
> On Mon, Nov 09, 2015 at 12:48:52PM +0800, Caesar Wang wrote:
> > Thank you all for providing inputs and comments on previous versions of
> > this patchset.
> > Especially thanks to the (Eduardo, Dmitry, Heiko,).
On 12 November 2015 at 21:33, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 04:24:50PM +, Peter Maydell wrote:
>> The existing device tree bindings assume that we are only trying to
>> describe a single address space with a device tree (for ARM, either
>> the Normal or the Secure world). Some u
On Thu, Nov 12, 2015 at 04:24:50PM +, Peter Maydell wrote:
> The existing device tree bindings assume that we are only trying to
> describe a single address space with a device tree (for ARM, either
> the Normal or the Secure world). Some uses for device tree need to
> describe both Normal and
On 11/06, Maxime Ripard wrote:
> Hi Stephen,
>
> Thanks for your feedback!
>
> On Fri, Oct 30, 2015 at 02:29:02PM -0700, Stephen Boyd wrote:
> > > +
> > > + mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> > > + if (!mux)
> > [..]
> > > + goto free_reset;
> > > + }
> > > +
> > > + return;
> > >
On 11/12, Rob Herring wrote:
> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
> > Some qcom based bootloaders identify the dtb blob based on a set
> > of device properties like SoC, platform, PMIC, and revisions of
> > those components. In downstream kernels, these values are added
>
On Thu, Nov 12, 2015 at 10:29:52AM -0800, Eduardo Valentin wrote:
> On Mon, Nov 09, 2015 at 12:48:52PM +0800, Caesar Wang wrote:
> > Thank you all for providing inputs and comments on previous versions of
> > this patchset.
> > Especially thanks to the (Eduardo, Dmitry, Heiko,).
> >
> > This s
On Mon, Nov 09, 2015 at 12:48:52PM +0800, Caesar Wang wrote:
> Thank you all for providing inputs and comments on previous versions of
> this patchset.
> Especially thanks to the (Eduardo, Dmitry, Heiko,).
>
> This series patchs are working for RK3368 on Rockchip platform.
Do you have any res
On Thu, Nov 12, 2015 at 09:51:20AM +0100, Boris Brezillon wrote:
> On Wed, 11 Nov 2015 16:26:04 -0800
> Brian Norris wrote:
>
> > We now stick the device node representing the current MTD (if any) into
> > sysfs, so let's make sure we have a reference to it before doing that.
> >
> > Suggested-b
* Neil Armstrong [151112 06:08]:
> In order to fix support for the dm816x platform, add missing bits in
> the dm816x dtsi and cleanup OCP.
Which ones are needed as fixes for the v4.4-rc kernel?
Regards,
Tony
> The last patch adds support for the omap4-hwspinlock.
>
> v2: add ocp hwmod cleanup
On Mon, Oct 26, 2015 at 05:40:57PM +0200, Yaniv Gardi wrote:
> UFS device and link can be put in multiple different low power modes
> hence UFS driver supports multiple different low power modes.
> By default UFS driver selects the default (optimal) low power mode
> (which gives moderate power savi
On Mon, Oct 26, 2015 at 10:24:17PM +0200, Constantine Shulyupin wrote:
> From: Constantine Shulyupin
>
> Introduced subnodes sensor, fan and peci with properties.
>
> Signed-off-by: Constantine Shulyupin
> ---
> Changed in v8:
> - added senor type "local"
> - Compatible nodes converted to senor
On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
> Some qcom based bootloaders identify the dtb blob based on a set
> of device properties like SoC, platform, PMIC, and revisions of
> those components. In downstream kernels, these values are added
> to the different component dtsi file
The existing device tree bindings assume that we are only trying to
describe a single address space with a device tree (for ARM, either
the Normal or the Secure world). Some uses for device tree need to
describe both Normal and Secure worlds in a single device tree. Add
documentation of how to do t
On 11/05/2015 08:41 PM, Rob Herring wrote:
> After the recent moving of DT binding documents, some maintainers entries
> are stale. Update them to the new locations.
>
> In bindings/fb/, there were only 2 files and I'm assuming the FB
> maintainers don't want to be copied on all of bindings/displ
On Mon, Oct 26, 2015 at 09:34:54PM +, Mans Rullgard wrote:
> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
> using the "aurora,nb8800" compatible string. When used in Sigma
> Designs chips a few additional features are available. These variants
> are indicated by a "sigma
Add the missing SPI controller DMA handler in the dm816x DT
node, only properties for the two channels on four were present.
Cc: Brian Hutchinson
Signed-off-by: Neil Armstrong
---
arch/arm/boot/dts/dm816x.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/b
Add missing #mbox-cells for dm816x mbox DT node.
Cc: Brian Hutchinson
Signed-off-by: Neil Armstrong
---
arch/arm/boot/dts/dm816x.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 3c99cfa..a7a34e4 100644
--- a/arch/arm/bo
Adds ti,timer-pwm property to timers 4 to 7 to permit usage of their
PWM output fonctionnality via the dmtimer driver.
Cc: Brian Hutchinson
Signed-off-by: Neil Armstrong
---
arch/arm/boot/dts/dm816x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arc
Remove invalid l3_main hwmod entry from dm816x DT ocp node.
Cc: Brian Hutchinson
Signed-off-by: Neil Armstrong
---
arch/arm/boot/dts/dm816x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 51ad4a9..b9feeea 100644
--- a/a
Add dm816x DT entries for omap4-hwspinlock support as hwmod spinbox.
Cc: Brian Hutchinson
Signed-off-by: Neil Armstrong
---
arch/arm/boot/dts/dm816x.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index b9feeea..eb9be
In order to fix support for the dm816x platform, add missing bits in
the dm816x dtsi and cleanup OCP.
The last patch adds support for the omap4-hwspinlock.
v2: add ocp hwmod cleanup
Neil Armstrong (5):
arm: dts: add dm816x missing #mbox-cells
arm: dts: add dm816x missing spi DT dma handles
On Tue, Oct 27, 2015 at 01:36:36PM +0100, Heiko Schocher wrote:
> remove tps65217.dtsi and adapt all boards, which
> used it.
>
> Signed-off-by: Heiko Schocher
> Tested-by: Keerthy
> Acked-by: Mark Brown
Acked-by: Rob Herring
> ---
> Suggested by Mark Brown, see:
> https://lkml.org/lkml/2015
On Thursday 12 November 2015 16:20:15 Fengguang Wu wrote:
> Hi Arnd,
>
> On Wed, Nov 11, 2015 at 09:42:00AM +0100, Arnd Bergmann wrote:
> > On Wednesday 11 November 2015 10:21:03 Fengguang Wu wrote:
> > > Hi Sinan,
> > >
> > > Sorry please ignore this warning -- it's actually a problem specific
>
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt |
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is differ
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 ++
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
-
On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote:
> Hi Eddie,
>
> Kevin Hilman writes:
>
> > Eddie Huang writes:
> >
> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote:
> >>> Hi Eddie,
> >>>
> >>> [...]
> >>>
> >>> > I check the log [0],
> >>>
> >>> Thanks for checking into this
Hi Russell,
On 11/10/2015 9:55 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 10, 2015 at 09:33:12PM +0530, Kapil Hali wrote:
>> Hi Russel,
>
> Wrong. Look at my name as sent in the From: and as quoted in the very
> next line. As far as I'm concerned (and I don't care what other people
> say
Hi Zain,
I was able to sucessfully test your crypto-driver, but have found some
improvements below that should probably get looked at:
Am Mittwoch, 11. November 2015, 14:35:58 schrieb Zain Wang:
> Crypto driver support:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You
On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote:
> > This is on-chip RAM or nornal system RAM? We already have bindings
> for
> > both.
>
> Juno has a set of TLX (ThinLinks) connectors on the board where an
> FPGA can be attached. On r1
> the code running on FPGA can even participate as an AX
On Thu, Nov 12, 2015 at 10:52:25AM +, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote:
> > > This is on-chip RAM or nornal system RAM? We already have bindings
> > for
> > > both.
> >
> > Juno has a set of TLX (ThinLinks) connectors on the board where an
> > F
On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote:
> > Cc: Rob Herring
> > Cc: Pawel Moll
> > Cc: Mark Rutland
> > Cc: Ian Campbell
> > Cc: Kumar Gala
> >
> > Signed-off-by: Liviu Dudau
>
> Looks pretty good, but a few
Hi Simon,
On Thu, Nov 12, 2015 at 2:53 AM, Simon Horman
wrote:
> In general Renesas hardware is not documented to the extent where the
> relationship between IP blocks on different SoCs can be assumed although
> they may appear to operate the same way. Furthermore the documentation
> typically do
Hi Jacek,
On 2015년 11월 12일 18:21, Jacek Anaszewski wrote:
> Hi Ingi,
>
> On 11/12/2015 08:57 AM, Ingi Kim wrote:
> [...]
+regmap_write(led->regmap, RT5033_REG_FLED_FUNCTION1, val);
+} else {
+regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
+
Hi Simon,
On Thu, Nov 12, 2015 at 2:15 AM, Simon Horman wrote:
> On Tue, Nov 10, 2015 at 09:35:06AM +0100, Geert Uytterhoeven wrote:
>> As of commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
>> dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
>> partitions in a
Am Mittwoch, 11. November 2015, 14:35:59 schrieb Zain Wang:
> Add Crypto node for rk3288 including crypto controller and dma clk.
>
> Signed-off-by: Zain Wang
I'd like to pick this one and the clock-patch2 up, once the crypto
driver itself got accepted and we have an Ack from the clock-maintaine
Am Mittwoch, 11. November 2015, 14:35:55 schrieb Zain Wang:
> This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc),
> and the more algorithms and new hash drivers will be added later on.
I gave this a spin using tcrypt on my rk3288 chromebook and it seems to
work nicely for mo
Hi Yakir,
Am Donnerstag, 12. November 2015, 10:36:51 schrieb Yakir Yang:
> On 11/12/2015 07:23 AM, Heiko Stuebner wrote:
> > Am Mittwoch, 28. Oktober 2015, 16:30:33 schrieb Yakir Yang:
> >> Add phy driver for the Rockchip DisplayPort PHY module. This
> >> is required to get DisplayPort working in
Hi Ingi,
On 11/12/2015 08:57 AM, Ingi Kim wrote:
[...]
+regmap_write(led->regmap, RT5033_REG_FLED_FUNCTION1, val);
+} else {
+regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
+ RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL |
+ rt503
On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>
>
> On 11/10/2015 07:14 PM, Peter Chen wrote:
> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> >> This fixes a bug where if you disconnect and re-connect the USB cable,
> >> the gadget driver stops working.
> >>
> >> Add s
Hi Milo,
On 11/11/2015 03:16 AM, Kim, Milo wrote:
Hi Jacek,
On 11/10/2015 10:44 PM, Jacek Anaszewski wrote:
+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
>>>+ struct device_attribute *attr,
>>>+ const char *buf, size_t l
On Thu, Nov 12, 2015 at 09:57:07AM +0100, Frans Klaver wrote:
> On Thu, Nov 12, 2015 at 9:53 AM, Uwe Kleine-König
> wrote:
> > CC += devicetree@vger.kernel.org, gregkh
>
> You added linux@pengutronix instead of devicetree.
Well I substituted Sascha by ker...@pengutronix.de on purpose, but
consid
On Wed, 11 Nov 2015 16:26:04 -0800
Brian Norris wrote:
> We now stick the device node representing the current MTD (if any) into
> sysfs, so let's make sure we have a reference to it before doing that.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Brian Norris
Looks good to me,
Reviewed
Am Donnerstag, 12. November 2015, 09:13:20 schrieb Zain:
>
> On 2015年11月12日 07:57, Heiko Stuebner wrote:
> > Am Mittwoch, 11. November 2015, 14:35:57 schrieb Zain Wang:
> >> Set an ID for crypto clk, so that it can be called in other part.
> >>
> >> Signed-off-by: Zain Wang
> > this should go in
Hi Arnd,
On Wed, Nov 11, 2015 at 09:42:00AM +0100, Arnd Bergmann wrote:
> On Wednesday 11 November 2015 10:21:03 Fengguang Wu wrote:
> > Hi Sinan,
> >
> > Sorry please ignore this warning -- it's actually a problem specific
> > to the mn10300 arch. I'll disable such warning in mn10300 in future.
On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
> Any overlap in the reserved memory regions (those specified in the
> reserved-memory DT node) is a bug. These bugs might go undetected as
> long as the contested region isn't used simultaneously by multiple
> software agents, which mak
95 matches
Mail list logo
