On wto, 2014-05-27 at 11:56 +0530, Yadwinder Singh Brar wrote:
> Hi Krzysztof,
>
>
> On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
> wrote:
> > Prepare for merging the s2mpa01 regulator driver into s2mps11 by:
> > 1. Adding common id for buck regulators.
> > 2. Splitting shared ramp delay
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
wrote:
> Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
> s2mpa01 regulator driver.
>
> Signed-off-by: Krzysztof Kozlowski
> @@ -216,30 +250,20 @@ static int s2mps11_set_ramp_delay(struct regulator_dev
> *rdev, int ra
Hi Thierry,
On 05/26/2014 03:41 PM, Thierry Reding wrote:
> On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources, display timings and cpu mode timings.
>>
>> Signed-off-by: YoungJun Cho
>> Acked-b
From: "Ivan T. Ivanov"
Add "power-source" property to generic options used for DT parsing files.
This enables drivers, which use generic pin configurations, to get the
value passed to this property.
Signed-off-by: Ivan T. Ivanov
---
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.t
Hi Krzysztof,
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
wrote:
> Prepare for merging the s2mpa01 regulator driver into s2mps11 by:
> 1. Adding common id for buck regulators.
> 2. Splitting shared ramp delay settings to match S2MPA01.
> 3. Adding a configuration of registers for settin
Hi,
On Thursday 15 May 2014 06:03 PM, Nishanth Menon wrote:
> On 05/15/2014 07:18 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 15 May 2014 05:42 PM, Nishanth Menon wrote:
>>> On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I
>>> wrote:
Hi Nishant,
On Thursday 1
Hi Arnd,
Thanks for the kind suggestions.
On 05/26/2014 10:51 PM, Arnd Bergmann wrote:
On Monday 19 May 2014, Zhangfei Gao wrote:
I only noticed one real issue with the driver:
+struct hix5hd2_desc {
+ __le32 buff_addr;
+ __le32 buff_len:11;
+ __le32 reserve2:5;
+ __l
On 05/26/2014 05:32 PM, Sebastian Reichel wrote:
On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote:
On 05/26/2014 03:36 PM, Sebastian Reichel wrote:
On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
After thinking about it more, I think it is very likely that removing
a
iginal work by Ben Dooks .
>
>
>>> Signed-off-by: Sergei Shtylyov
>
>
>>> ---
>>> This patch is against 'renesas-devel-v3.15-rc7-20140526' tag of Simon
>>> Horman's
>>> 'renesas.git' repo plus R8A7790/Lager PCI and
On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote:
> On 05/26/2014 03:36 PM, Sebastian Reichel wrote:
> >On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
> >>After thinking about it more, I think it is very likely that removing
> >>all the overlays is the correct thing to d
On 05/26/2014 02:44 PM, Geert Uytterhoeven wrote:
Hi Grant,
On Mon, May 26, 2014 at 11:33 PM, Grant Likely
wrote:
After thinking about it more, I think it is very likely that removing
all the overlays is the correct thing to do in the kexec use-case. When
kexec-ing, it makes sense that we'd wa
On 05/26/2014 03:36 PM, Sebastian Reichel wrote:
Hi,
On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
After thinking about it more, I think it is very likely that removing
all the overlays is the correct thing to do in the kexec use-case. When
kexec-ing, it makes sense that we'd wa
Hi,
On Mon, May 26, 2014 at 08:14:08AM -0700, Guenter Roeck wrote:
> On 05/26/2014 08:09 AM, Sebastian Reichel wrote:
> >On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
> >>On May 26, 2014, at 2:23 PM, Grant Likely wrote:
> >>>On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoev
5-rc7-20140526' tag of Simon Horman's
'renesas.git' repo plus R8A7790/Lager PCI and USB PHY support patches posted
before. The patch requires the internal PCI DT support, USB PHY driver, and
USB HCD generic PHY support (also already posted) in order to work.
Changes in version
Hi,
On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
> After thinking about it more, I think it is very likely that removing
> all the overlays is the correct thing to do in the kexec use-case. When
> kexec-ing, it makes sense that we'd want the exact same behaviour from
> the kexec'e
h is against 'renesas-devel-v3.15-rc7-20140526' tag of Simon Horman's
> 'renesas.git' repo plus R8A7790/Lager PCI and USB PHY support patches posted
> before. The patch requires the internal PCI DT support, USB PHY driver, and
> USB HCD generic PHY support (al
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-v3.15-rc7-20140526' tag of Simon Horman's
'renesas.git' repo plus R8A7791/Koelsch/Henninge
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Based on the original work by Ben Dooks .
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-v3.15-rc7-20140526' tag of Simon Horman's
're
On 05/26/14 20:11, Tomasz Figa wrote:
Hi,
Hi
On 26.05.2014 05:23, Tarek Dakhran wrote:
The series of patches represent support of Exynos 5410 SoC
The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture
Patches add new platform description, support of clock controller and
Hi Grant,
On Mon, May 26, 2014 at 11:33 PM, Grant Likely
wrote:
> After thinking about it more, I think it is very likely that removing
> all the overlays is the correct thing to do in the kexec use-case. When
> kexec-ing, it makes sense that we'd want the exact same behaviour from
> the kexec'ed
SolidRun is a company from Israel producing small-sized home-media
computers like the Marvell Dove based CuBox and Freescale IMX based
CuBox-i. Document the missing vendor prefix.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kum
As Mainlining effort for SolidRun CuBox has been carried out on the
Engineering Sample, the board DTS was reflecting this. Actually,
SolidRun CuBox comes in three different variants: Engineering Sample (ES),
production with 1GB RAM (1G), and production with 2GB RAM (2G).
Therefore, we split the cu
On Mon, 26 May 2014 14:55:37 +0300, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On May 26, 2014, at 2:23 PM, Grant Likely wrote:
>
> > On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
> > wrote:
> >> Hi Grant,
> >>
> >> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> >> wrote:
> >>> On
CC devicetree for the bindings
On Mon, May 26, 2014 at 10:31 PM, Stefan Kristiansson
wrote:
> In addition to consolidating the or1k-pic with other interrupt
> controllers, this makes OpenRISC less tied to its on-cpu
> interrupt controller.
>
> All or1k-pic specific parts are moved out of irq.c an
Use more compact of_property_read_{bool|u32}() calls instead of the
of_{find|get}_property() calls in of_get_regulation_constraints() where
possible (note that of_property_read_{bool|u32}() were already used to read
some properties).
Signed-off-by: Sergei Shtylyov
---
The patch is against Mark B
On Mon, May 26, 2014 at 12:20 PM, Heiko Stübner wrote:
> Am Montag, 26. Mai 2014, 11:13:15 schrieb Olof Johansson:
>> On Thu, Mar 27, 2014 at 01:06:32AM +0100, Heiko Stübner wrote:
>> > With the newly introduced CPU_METHOD_OF_DECLARE is not necessary anymore
>> > to reference the relevant smp_ops
Am Montag, 26. Mai 2014, 11:13:15 schrieb Olof Johansson:
> On Thu, Mar 27, 2014 at 01:06:32AM +0100, Heiko Stübner wrote:
> > With the newly introduced CPU_METHOD_OF_DECLARE is not necessary anymore
> > to reference the relevant smp_ops in the board file, but instead it can
> > simply be set by th
Aggreagation of version 1-2 because of version 1 can hit
PLB errors too. If it's not set so we missing events for PLB bits
and driver can't process those interrupts.
Signed-off-by: Ivan Mikhaylov
---
drivers/net/ethernet/ibm/emac/mal.c | 5 +
drivers/net/ethernet/ibm/emac/mal.h | 20 ++
In chips of emac/rgmii b'000' for 0/1 channel isn't suitable which
resulted in non working network interface in this mode.
Signed-off-by: Ivan Mikhaylov
---
drivers/net/ethernet/ibm/emac/rgmii.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ibm/emac/rgmii.c
b/driv
On Mon, May 26, 2014 at 10:01:40PM +0400, Sergei Shtylyov wrote:
> On 05/26/2014 09:56 PM, Mark Brown wrote:
> >By avoiding CCing lkml you avoided CCing the list where regulator
> >patches are discussed. When using get_maintainers.pl you need to think
> >about what it's telling you.
>The pro
On Thu, Mar 27, 2014 at 01:06:32AM +0100, Heiko Stübner wrote:
> With the newly introduced CPU_METHOD_OF_DECLARE is not necessary anymore
> to reference the relevant smp_ops in the board file, but instead it can
> simply be set by the enable-method property of the cpu nodes.
>
> Signed-off-by: Hei
On Mon, May 26, 2014 at 3:01 PM, Sergei Shtylyov
wrote:
>> By avoiding CCing lkml you avoided CCing the list where regulator
>> patches are discussed. When using get_maintainers.pl you need to think
>> about what it's telling you.
>
>
>The problem with LKML is that it's always suggested, eve
On 05/26/2014 09:56 PM, Mark Brown wrote:
Always CC mailing lists on patches.
Er, I did CC devicetree@vger.kernel.org but (as usual) avoided CCing LKML
-- that's all the lists scripts/get_maintainer.pl suggested. Do you mean
some other list I don't know about?
By avoiding CCing lkml yo
On Mon, May 26, 2014 at 09:33:34PM +0400, Sergei Shtylyov wrote:
> On 05/26/2014 07:19 PM, Mark Brown wrote:
> > Always CC mailing lists on patches.
>Er, I did CC devicetree@vger.kernel.org but (as usual) avoided CCing LKML
> -- that's all the lists scripts/get_maintainer.pl suggested. Do you
Hi,
On 05/26/2014 06:07 PM, Ulf Hansson wrote:
> [snip]
>
>>>
>>> We don't typically actually bind multiple compatibles for a single
>>> device. We've got a bunch of options we can choose from but we
>>> generally pick the one that matches best and ignore the others.
>>>
Where as what you'r
Hello.
On 05/26/2014 07:19 PM, Mark Brown wrote:
Use more compact of_property_read_{bool|u32}() calls instead of the
of_{find|get}_property() calls.
Applied, thanks.
Thank you for the quick reply! :-)
Always CC mailing lists on patches.
Er, I did CC devicetree@vger.kernel.org bu
2014-05-26 15:45 GMT+02:00 Georgi Djakov :
> On 23.05.14, 19:39, Matthias Brugger wrote:
>>
>> 2014-05-23 17:12 GMT+02:00 Georgi Djakov :
>>>
>>> Add information about the APQ8084 debug UART physical and virtual
>>> addresses in the DEBUG_QCOM_UARTDM Kconfig help section.
>>> Requires: https://lkml
On 26 May 2014 21:27, Lucas Stach wrote:
> No, we need the regulator to determine which OPPs are actually useable.
> If the regulator is only supplying 1.1V we can only scale to 800MHz max,
> which is the case for some of the industrial i.MX53 versions.
Go and add another binding for this max-vol
On Mon, May 26, 2014 at 06:07:18PM +0200, Ulf Hansson wrote:
> >> I'm not sure I'm buying the idea that we have a powerup driver that's
> >> meaningfully not part of the main device driver.
> I am having a bit hard to follow the terminology here. :-) What is a
> "powerup driver" and what is a "ma
[snip]
>>
>> We don't typically actually bind multiple compatibles for a single
>> device. We've got a bunch of options we can choose from but we
>> generally pick the one that matches best and ignore the others.
>>
>>> Where as what you're suggesting is to always pick driver foo, unless
>>> driv
Am Montag, den 26.05.2014, 21:05 +0530 schrieb Viresh Kumar:
> On 26 May 2014 20:58, Lucas Stach wrote:
> > The platform I'm working on supports cpu rail voltage regulation just
> > fine.
>
> So, the regulator can be scaled to support all values from your dts
> and we can work without MAX-volt pa
On Mon, May 26, 2014 at 04:45:39PM +0800, Sean Cross wrote:
> The PFUZE100 supports enabling/disabling of SWB regulators, but the driver
> doesn't currently support this. The first patch adds support for the
> enable/disable bit.
Applied, thanks.
signature.asc
Description: Digital signature
On 26 May 2014 20:58, Lucas Stach wrote:
> The platform I'm working on supports cpu rail voltage regulation just
> fine.
So, the regulator can be scaled to support all values from your dts
and we can work without MAX-volt parameter here..
> I just want to make sure that the driver works properly
Am Montag, den 26.05.2014, 20:52 +0530 schrieb Viresh Kumar:
> On 26 May 2014 19:28, Lucas Stach wrote:
> > Right, the OPP in my example define the minimum required voltage for
> > each frequency. This is in accordance to the OPP binding. But for this
> > chip the datasheet explicitly says that it
On 26/5/2014 10:57 PM, Mark Brown wrote:
On Mon, May 26, 2014 at 04:45:40PM +0800, Sean Cross wrote:
+ .enable_reg = (base), \
+ .enable_mask = 0x48,\
I note that this is a two bit field - what do the two bits mean?
The datasheet defines the r
On 26 May 2014 19:28, Lucas Stach wrote:
> Right, the OPP in my example define the minimum required voltage for
> each frequency. This is in accordance to the OPP binding. But for this
> chip the datasheet explicitly says that it is ok to power the cpu rail
> with up to 1.4V, regardless of the cur
On Mon, May 26, 2014 at 01:58:22PM +0530, Tushar Behera wrote:
> If master clock is provided through device tree, then update
> the master clock frequency during set_sysclk.
Applied, thanks.
signature.asc
Description: Digital signature
On Sun, May 25, 2014 at 11:50:39PM +0400, Sergei Shtylyov wrote:
> Use more compact of_property_read_{bool|u32}() calls instead of the
> of_{find|get}_property() calls.
Applied, thanks. Always CC mailing lists on patches.
signature.asc
Description: Digital signature
On Mon, May 26, 2014 at 01:58:21PM +0530, Tushar Behera wrote:
> If master clock is provided through device tree, then update
> the master clock frequency during set_sysclk.
Applied, thanks.
signature.asc
Description: Digital signature
Hi Sebastian,
On May 26, 2014, at 6:09 PM, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
>> On May 26, 2014, at 2:23 PM, Grant Likely wrote:
>>> On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
>>> wrote:
>>> Heeheehee. We're back w
On 05/26/2014 08:09 AM, Sebastian Reichel wrote:
Hi,
On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
On May 26, 2014, at 2:23 PM, Grant Likely wrote:
On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
wrote:
Heeheehee. We're back where we started. The original question
Hi,
On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
> On May 26, 2014, at 2:23 PM, Grant Likely wrote:
> > On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
> > wrote:
> > Heeheehee. We're back where we started. The original question is whether
> > or not that is a valid
Hi,
On 05/26/2014 04:22 PM, Mark Brown wrote:
> On Mon, May 26, 2014 at 01:12:43PM +0200, Hans de Goede wrote:
>> On 05/26/2014 12:38 PM, Mark Brown wrote:
>>> On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
>
>>> until we've powered up and enumerated. The only time that there's a
On Mon, May 26, 2014 at 04:45:40PM +0800, Sean Cross wrote:
> + .enable_reg = (base), \
> + .enable_mask = 0x48,\
I note that this is a two bit field - what do the two bits mean?
signature.asc
Description: Digital signature
On Mon, May 26, 2014 at 10:38:14AM +0200, Philipp Zabel wrote:
> Add Linear Technology Corporation to the list of device tree vendor prefixes.
Applied, thanks.
signature.asc
Description: Digital signature
The libahci now allows to use multiple PHYs and to represent each port
as a sub-node. Add these bindings to the documentation.
Signed-off-by: Antoine Ténart
---
.../devicetree/bindings/ata/ahci-platform.txt | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff -
The Berlin SATA PHY drives the PHY related to the SATA interface. Add
the corresponding documentation.
Signed-off-by: Antoine Ténart
---
Documentation/devicetree/bindings/phy/berlin-sata-phy.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bi
The Berlin SoC has a two SATA ports. Add a PHY driver to handle them.
The mode selection can let us think this PHY can be configured to fit
other purposes. But there are reasons to think the SATA mode will be
the only one usable: the PHY registers are only accessible indirectly
through two registe
The BG2Q has an AHCI SATA controller. Add the corresponding nodes
(AHCI, PHY) into its device tree.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2q.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/d
On Monday 19 May 2014, Zhangfei Gao wrote:
I only noticed one real issue with the driver:
> +struct hix5hd2_desc {
> + __le32 buff_addr;
> + __le32 buff_len:11;
> + __le32 reserve2:5;
> + __le32 data_len:11;
> + __le32 reserve1:2;
> + __le32 fl:2;
> + __le32 descvid:1;
The BG2Q has an AHCI SATA controller with an eSATA interface. Enable it.
Only enable the first port, the BG2Q DMP does not support the second one.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boo
The current implementation of the libahci does not allow to use multiple
PHYs. This patch adds the support of multiple PHYs by the libahci while
keeping the old bindings valid for device tree compatibility.
This introduce a new way of defining SATA ports in the device tree, with
one port per sub-n
The ahci_platform driver is a generic driver using the libahci_platform
functions. Add a generic compatible to avoid having an endless list of
compatibles with no differences for the same driver.
Signed-off-by: Antoine Ténart
---
drivers/ata/ahci_platform.c | 2 ++
1 file changed, 2 insertions(+
This series adds the support for Berlin SoC AHCI controller. The
controller allows to use the SATA host interface and, for example, the
eSATA port on the BG2Q.
The series adds a PHY driver to control the two SATA ports available,
and adds a generic compatible to use the existing ahci_platform driv
On 26 May 2014 13:35, Jaehoon Chung wrote:
> From: Ludovic Desroches
>
> Some hosts manage several slots. In these case information such as the
> bus width, chip detect and others are into the slot node. So we have to
> parse child node. If not NULL, slot node will be used instead of the
> device
On Mon, May 26, 2014 at 01:12:43PM +0200, Hans de Goede wrote:
> On 05/26/2014 12:38 PM, Mark Brown wrote:
> > On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
> > until we've powered up and enumerated. The only time that there's a
> > problem and would need to specify exactly what
Am Montag, den 26.05.2014, 19:14 +0530 schrieb Viresh Kumar:
> On 26 May 2014 18:41, Lucas Stach wrote:
>
> Just to mention that I am trying to help you and am not opposing any
> change. We can add this field if its really required and I am just trying
> to understand your problem and if we can s
Oops, sent this series out by mistake. Sorry for the noise.
g.
On Mon, May 26, 2014 at 2:42 PM, Grant Likely wrote:
> From: Leif Lindholm
>
> The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
> its memory node, relying on an old ppc quirk in order to discover its
> memory. F
On 23.05.14, 19:39, Matthias Brugger wrote:
2014-05-23 17:12 GMT+02:00 Georgi Djakov :
Add information about the APQ8084 debug UART physical and virtual
addresses in the DEBUG_QCOM_UARTDM Kconfig help section.
Requires: https://lkml.org/lkml/2014/4/14/312
Signed-off-by: Georgi Djakov
---
arch
On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu mode timings.
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> .../devicetree/b
On 26 May 2014 18:41, Lucas Stach wrote:
Just to mention that I am trying to help you and am not opposing any
change. We can add this field if its really required and I am just trying
to understand your problem and if we can solve it with current code.
> No, setting voltage-tolerance to zero mea
From: Leif Lindholm
A few platforms lack a 'device_type = "memory"' for their memory
nodes, relying on an old ppc quirk in order to discover its memory.
Add the missing data so that all parsing code can find memory nodes
correctly.
Signed-off-by: Leif Lindholm
Cc: linux-m...@linux-mips.org
Cc:
From: Leif Lindholm
The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.
Signed-off-by: Leif Lindholm
Acked-by: Lee Jones
Acked-by: Linu
On Thu, May 22, 2014 at 05:31:49PM +0200, Andrew Lunn wrote:
> Some platforms require that the codecs mclk is a fixed multiplication
> factor of the audio stream rate. Add a optional property to the
> binding to hold this factor and implement a hw_params() function to
> make use of it.
Applied, th
Prepare for merging the s2mpa01 regulator driver into s2mps11 by:
1. Adding common id for buck regulators.
2. Splitting shared ramp delay settings to match S2MPA01.
3. Adding a configuration of registers for setting ramp delay for each
buck regulator.
The functionality of the driver should not
Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
s2mpa01 regulator driver.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 106
drivers/regulator/Kconfig | 4 +-
drivers/regulator/s2mps11.c
Hi,
The patchset merges s2mpa01 regulator driver into s2mps11. As a result
the s2mps11 supports:
- S2MPA01
- S2MPS11
- S2MPS14
These PMIC-s are very similar to each other and they are often used
along with Samsung's Exynos SoCs. Merging this into one driver has
two benefits:
- less code dupl
The s2mpa01 regulator driver can be safely removed since it was merged
into s2mps11 driver.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/mfd/s2mpa01.txt | 90
drivers/regulator/Kconfig | 7 -
drivers/regulator/Makefile
Am Montag, den 26.05.2014, 18:26 +0530 schrieb Viresh Kumar:
> On 26 May 2014 18:05, Lucas Stach wrote:
[...]
>
> > 2. Usage of a fixed max voltage, rather than a voltage-tolerance. i.MX5
> > has a fixed maximum voltage, which is valid across all operating points.
> > I'm really opposed to using
On Wed, May 14, 2014 at 12:35:18PM -0700, Mike Turquette wrote:
> Quoting Thierry Reding (2014-05-14 07:27:40)
[...]
> > As for shared clocks I'm only aware of one use-case, namely EMC scaling.
> > Using clocks for that doesn't seem like the best option to me. While it
> > can probably fix the imme
On 26 May 2014 18:05, Lucas Stach wrote:
> Ok I can push down the clock handling into the imx5 clk driver.
Great !!
> This leaves two more differences between imx5-cpufreq and cpufreq-cpu0:
>
> 1. Disabling of OPPs that could not be supported by the connected
> regulator. I think this part can e
Am Montag, den 26.05.2014, 16:36 +0530 schrieb Viresh Kumar:
> On 26 May 2014 16:15, Lucas Stach wrote:
> > This driver handles the i.MX5 specific clock reparenting to be able to
> > reprogramm the PLL. cpufreq-cpu0 can only change a postdivider of the
> > PLL, which means we can't reach the exact
From: Arun Kumar K
Adds IDs for MUX clocks to be used by power domain for MFC
for doing re-parenting while pd on/off.
Signed-off-by: Arun Kumar K
Signed-off-by: Shaik Ameer Basha
---
drivers/clk/samsung/clk-exynos5420.c |6 --
include/dt-bindings/clock/exynos5420.h |2 ++
2 file
From: Arun Kumar K
Adding the optional clock property for the mfc_pd for
handling the re-parenting while pd on/off.
Signed-off-by: Arun Kumar K
Signed-off-by: Shaik Ameer Basha
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/exynos5420.dtsi |3 +++
1 file changed, 3 insertions(+)
diff --
This patchset enables the clk handling in power domain for
working as per the recommended power domain on / off sequence for
exynos5 SoCs. I have posted an RFC for the same [1] and didnt get any
review comments / objections. So I am dropping the RFC tag and
posting the patch along with the required
From: Prathyush K
While powering on/off a local powerdomain in exynos5 chipsets, the input
clocks to each device gets modified. This behaviour is based on the
SYSCLK_SYS_PWR_REG registers.
E.g. SYSCLK_MFC_SYS_PWR_REG = 0x0, the parent of input clock to MFC
(aclk
Hi Grant,
On May 26, 2014, at 2:23 PM, Grant Likely wrote:
> On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
> wrote:
>> Hi Grant,
>>
>> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
>> wrote:
>>> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
>>> wrote:
On Tue, May 20,
From: Ludovic Desroches
Some hosts manage several slots. In these case information such as the
bus width, chip detect and others are into the slot node. So we have to
parse child node. If not NULL, slot node will be used instead of the
device node.
Signed-off-by: Ludovic Desroches
Signed-off-by
dw-mmc controller have the multiple slot.
Then it needs to parse the property for each slot.
Signed-off-by: Jaehoon Chung
---
Changelog V2:
- None
drivers/mmc/host/dw_mmc.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/
dw-mmc controller can be support the multiple slot.
So each slot's property can be difference.
Signed-off-by: Jaehoon Chung
---
Changelog V2:
- None
arch/arm/boot/dts/exynos4412-odroidx.dts |2 +-
arch/arm/boot/dts/exynos4412-origen.dts |2 +-
arch/arm/boot/dts/exynos
This patch-set is fixed the dw-mmc controller problem.
dw-mmc controller have the slot, but mmc_of_parse didn't parse the slot
sub-node.
So dw-mmc controller didn't work correctly.
Jaehoon Chung (2):
mmc: dw_mmc: use the __mmc_of_parse to parse the slot node
ARM: dts: replace the broken-cd pr
On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
wrote:
> Hi Grant,
>
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> wrote:
> > On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
> > wrote:
> >> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
> >> wrote:
> >> >> Why has the over
Hi,
On 05/26/2014 12:38 PM, Mark Brown wrote:
> On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
>> Also the mmc people are very much against specifying a driver, as that is
>> something which should be probed not specified. I agree with them I've
>> already seen boards were more
Hi,
On 26.05.2014 05:23, Tarek Dakhran wrote:
> The series of patches represent support of Exynos 5410 SoC
>
> The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture
>
> Patches add new platform description, support of clock controller and device
> tree for Exynos 5410.
>
> H
Hi Geert,
On May 26, 2014, at 1:57 PM, Geert Uytterhoeven wrote:
> Hi Grant,
>
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> wrote:
>> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
>> wrote:
>>> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
>>> wrote:
> Why has the overlay
Am Montag, 26. Mai 2014, 12:14:43 schrieb Thierry Reding:
> On Wed, May 21, 2014 at 01:42:56PM +0900, YoungJun Cho wrote:
> > This patch is based on videomode and display_timing relevant codes.
> > To support command mode panel, it does not need to guide its timing
> > information to the display co
On 26 May 2014 16:15, Lucas Stach wrote:
> This driver handles the i.MX5 specific clock reparenting to be able to
> reprogramm the PLL. cpufreq-cpu0 can only change a postdivider of the
> PLL, which means we can't reach the exact OPP frequencies and can not
> profit from the additional power savin
Thomas,
On 26.05.2014 08:05, Thomas Abraham wrote:
> Hi Tomasz,
>
> Thanks for your comments. Please see inline reply.
>
> On Sat, May 17, 2014 at 4:54 AM, Tomasz Figa wrote:
>> Hi Thomas,
>>
>> Please see my comments inline.
>>
>> On 14.05.2014 03:11, Thomas Abraham wrote:
>>> From; Thomas Abr
Hi Grant,
On Mon, May 26, 2014 at 12:48 PM, Grant Likely
wrote:
> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
> wrote:
>> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
>> wrote:
>> >> Why has the overlay system been designed for plugging and unpluging whole
>> >> overlays?
>> >> Th
On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
wrote:
> Hi Grant,
>
> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
> wrote:
> >> Why has the overlay system been designed for plugging and unpluging whole
> >> overlays?
> >> That means the kernel has to remember the full stack, causing
1 - 100 of 158 matches
Mail list logo
