> On Jan 28, 2017, at 1:00 AM, Alexandre Belloni
> <alexandre.bell...@free-electrons.com> wrote:
>
> On 28/01/2017 at 00:51:13 +0800, Jean-Christophe Plagniol-Villard wrote:
>> this does not mean I do not follow the ML
>>
>
> That's not what I'm
> On Jan 28, 2017, at 1:00 AM, Alexandre Belloni
> wrote:
>
> On 28/01/2017 at 00:51:13 +0800, Jean-Christophe Plagniol-Villard wrote:
>> this does not mean I do not follow the ML
>>
>
> That's not what I'm implying. Many people are following various maili
while.
>> Remove him from the maintainers
>>
>> Also, merge both AT91 pinctrl drivers entries.
>>
>> Cc: Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>> Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
>
>
from the maintainers
>>
>> Also, merge both AT91 pinctrl drivers entries.
>>
>> Cc: Jean-Christophe Plagniol-Villard
>> Signed-off-by: Alexandre Belloni
>
> Yes:
>
> Acked-by: Nicolas Ferre
>
> Thanks, regards,
>
>> ---
>> Also,
t to be copied on all of bindings/display/. So I've
> dropped them.
>
> Reported-by: Thierry Reding
> Cc: Thierry Reding
> Cc: Jianwei Wang
> Cc: Alison Wang
> Cc: Philipp Zabel
> Cc: Mark Yao
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Jean-Christophe Pla
ison Wang <alison.w...@freescale.com>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Cc: Mark Yao <mark@rock-chips.com>
> Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
> Cc: Vincent Abriou <vincent.abr...@st.com>
> Cc: Jean-Christophe Plagniol-Villard <plag
> On Jul 13, 2015, at 9:00 PM, Ludovic Desroches
> wrote:
>
> On Mon, Jul 13, 2015 at 02:14:51PM +0800, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>>
>>> On Jul 3, 2015, at 12:06 AM, David Dueck wrote:
>>>
>>> Not all gpio banks are necessaril
> On Jul 3, 2015, at 12:06 AM, David Dueck wrote:
>
> Not all gpio banks are necessarily enabled, in the current code this can
> lead to null pointer dereferences.
>
> [ 51.13] Unable to handle kernel NULL pointer dereference at virtual
> address 0058
> [ 51.13] pgd = dee04000
On Jul 3, 2015, at 12:06 AM, David Dueck davidcdu...@googlemail.com wrote:
Not all gpio banks are necessarily enabled, in the current code this can
lead to null pointer dereferences.
[ 51.13] Unable to handle kernel NULL pointer dereference at virtual
address 0058
[
On Jul 13, 2015, at 9:00 PM, Ludovic Desroches ludovic.desroc...@atmel.com
wrote:
On Mon, Jul 13, 2015 at 02:14:51PM +0800, Jean-Christophe PLAGNIOL-VILLARD
wrote:
On Jul 3, 2015, at 12:06 AM, David Dueck davidcdu...@googlemail.com wrote:
Not all gpio banks are necessarily enabled
> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult
> wrote:
>
> Am 29.05.2015 um 05:31 schrieb Rob Landley:
>
> >> What's the big deal with having DTS/DTB under GPL ?
>>
>> One problem is that there's no such thing as "The GPL" anymore.
>
> There are different versions. The
On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult
weig...@melag.de wrote:
Am 29.05.2015 um 05:31 schrieb Rob Landley:
What's the big deal with having DTS/DTB under GPL ?
One problem is that there's no such thing as The GPL anymore.
There are different versions. The
On 20:59 Mon 16 Mar , Fabian Frederick wrote:
> of_device_id is always used as const.
> (See driver.of_match_table and open firmware functions)
>
> Signed-off-by: Fabian Frederick
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
Best Regards,
J.
> ---
> drivers/pinctrl/bcm
On 20:59 Mon 16 Mar , Fabian Frederick wrote:
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick f...@skynet.be
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Best Regards,
J.
---
drivers
ve been created to address this
> problem.
>
> Move gpiochip_lock/unlock_as_irq calls into
> irq_request/release_resources functions to prevent using a gpio as an irq
> if the gpiochip_lock_as_irq call failed.
>
> Signed-off-by: Boris Brezillon
Linus
Acked-by: Jean-Christoph
On 17:26 Wed 04 Mar , Nicolas Ferre wrote:
> Signed-off-by: Nicolas Ferre
please keep in Cc for at91 related work
Best Regards,
J.
> ---
> arch/arm/boot/dts/sama5d3.dtsi | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi
On 17:26 Wed 04 Mar , Nicolas Ferre wrote:
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
please keep in Cc for at91 related work
Best Regards,
J.
---
arch/arm/boot/dts/sama5d3.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git
this
problem.
Move gpiochip_lock/unlock_as_irq calls into
irq_request/release_resources functions to prevent using a gpio as an irq
if the gpiochip_lock_as_irq call failed.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Linus
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn
> On Mar 2, 2015, at 6:57 PM, Alexandre Belloni
> wrote:
>
> On 02/03/2015 at 18:50:27 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
>>
>>> On Mar 2, 2015, at 6:42 PM, Alexandre Belloni
>>> wrote:
>>>
>>> On some platforms, th
> On Mar 2, 2015, at 6:42 PM, Alexandre Belloni
> wrote:
>
> On some platforms, there are multiple SRAM nodes defined in the device tree
> but
> some of them are disabled, leading to allocation failure. Try to find the
> first
> enabled SRAM node and allocate from it.
>
> Signed-off-by:
On Mar 2, 2015, at 6:42 PM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On some platforms, there are multiple SRAM nodes defined in the device tree
but
some of them are disabled, leading to allocation failure. Try to find the
first
enabled SRAM node and allocate from
On Mar 2, 2015, at 6:57 PM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On 02/03/2015 at 18:50:27 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
On Mar 2, 2015, at 6:42 PM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On some platforms
> On Feb 26, 2015, at 9:32 PM, Nicolas Ferre wrote:
>
> Le 08/02/2015 19:23, Boris Brezillon a écrit :
>> The gpiochip_lock_as_irq call can fail and return an error, while the
>> irq_startup is not expected to fail (returns an unsigned int which is not
>> checked by irq core code).
>>
>>
On Feb 26, 2015, at 9:32 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
Le 08/02/2015 19:23, Boris Brezillon a écrit :
The gpiochip_lock_as_irq call can fail and return an error, while the
irq_startup is not expected to fail (returns an unsigned int which is not
checked by irq core
> On Feb 24, 2015, at 3:45 PM, Michal Simek wrote:
>
> This driver is used on new Xilinx ZynqMP SoC.
>
> Signed-off-by: Michal Simek
> Acked-by: Sören Brinkmann
> ---
>
> drivers/net/ethernet/cadence/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Feb 24, 2015, at 3:45 PM, Michal Simek michal.si...@xilinx.com wrote:
This driver is used on new Xilinx ZynqMP SoC.
Signed-off-by: Michal Simek michal.si...@xilinx.com
Acked-by: Sören Brinkmann soren.brinkm...@xilinx.com
---
drivers/net/ethernet/cadence/Kconfig | 4 ++--
1 file
> On Feb 9, 2015, at 10:50 PM, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
>
>> On Feb 9, 2015, at 2:23 AM, Boris Brezillon
>> wrote:
>>
>> The gpiochip_lock_as_irq call can fail and return an error, while the
>> irq_startup is not expec
On Feb 9, 2015, at 10:50 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On Feb 9, 2015, at 2:23 AM, Boris Brezillon
boris.brezil...@free-electrons.com wrote:
The gpiochip_lock_as_irq call can fail and return an error, while the
irq_startup is not expected to fail
> On Feb 9, 2015, at 2:23 AM, Boris Brezillon
> wrote:
>
> The gpiochip_lock_as_irq call can fail and return an error, while the
> irq_startup is not expected to fail (returns an unsigned int which is not
> checked by irq core code).
>
> irq_request/release_resources functions have been
On Feb 9, 2015, at 2:23 AM, Boris Brezillon
boris.brezil...@free-electrons.com wrote:
The gpiochip_lock_as_irq call can fail and return an error, while the
irq_startup is not expected to fail (returns an unsigned int which is not
checked by irq core code).
irq_request/release_resources
> On Jan 28, 2015, at 3:19 PM, Pavel Machek wrote:
>
> Hi!
>
>>> In other words, what prevents someone from creating, say, a custom
>>> minimal Barebox version that sits on top of the existing N900
>>> bootloader? Wouldn't that provide a much better user experience?
>>
>> I do agree with
> On Jan 28, 2015, at 9:58 PM, Pali Rohár wrote:
>
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux [150127
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>>
> On Jan 28, 2015, at 11:57 PM, Rob Herring wrote:
>
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre wrote:
>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>>
>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
On omaps, the bootrom passes the bootreason in r1 to the
On Jan 28, 2015, at 11:57 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 28 Jan 2015, Pali Rohár wrote:
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
On omaps, the bootrom passes the bootreason in
On Jan 28, 2015, at 9:58 PM, Pali Rohár pali.ro...@gmail.com wrote:
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [150127
09:51]:
We _could_ (and have in the past) turned round and refused
to support these kinds of hacks -
On Jan 28, 2015, at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
I do agree with
> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre wrote:
>
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
Or we pass both the ATAGs and wrapped DT to the kernel
On Jan 28, 2015, at 10:07 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
Or we pass both the ATAGs and wrapped DT to the
> On Jan 23, 2015, at 12:07 AM, Nicolas Ferre wrote:
>
> Newer SoCs: at91sam9x5, at91sam9n12, sama5d3 and sama5d4 embed a DDR
> controller
> and have a different PMC status register layout than the at91sam9g45. Create
> another at91_sam9x5_pm_init() function to match this compatibility.
>
>
On Jan 23, 2015, at 12:07 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
Newer SoCs: at91sam9x5, at91sam9n12, sama5d3 and sama5d4 embed a DDR
controller
and have a different PMC status register layout than the at91sam9g45. Create
another at91_sam9x5_pm_init() function to match this
> On Jan 15, 2015, at 4:21 AM, Boris Brezillon
> wrote:
>
> Hi Jean-Christophe,
>
> On Wed, 14 Jan 2015 20:14:12 +0100
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>> On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
>>> Store SoC differenc
On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
> Store SoC differences in a struct to remove cpu_is_* usage.
>
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/mach-at91/pm.c | 54
> ++---
> 1 file changed, 33 insertions(+), 21 deletions(-)
>
On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
Store SoC differences in a struct to remove cpu_is_* usage.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c | 54
++---
1 file changed, 33
On Jan 15, 2015, at 4:21 AM, Boris Brezillon
boris.brezil...@free-electrons.com wrote:
Hi Jean-Christophe,
On Wed, 14 Jan 2015 20:14:12 +0100
Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote:
On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
Store SoC differences
> On Jan 14, 2015, at 12:16 AM, Sascha Hauer wrote:
>
> On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
I am worried that there is something in your reasoning that sort of
assumes all pin controllers mux pins one-by-one and not in groups.
How do we make it
On Jan 14, 2015, at 12:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
I am worried that there is something in your reasoning that sort of
assumes all pin controllers mux pins one-by-one and not in groups.
How do we make it
Hi,
This is a bit weird as the clock of the TC should be off and the irq
free
so this should never happened we need to investigate more why this
append
Best Regards,
J.
On Aug 20, 2014, at 6:07 AM, Gaël PORTAY wrote:
>
> Shutdown properly the timer counter block by masking
Hi,
This is a bit weird as the clock of the TC should be off and the irq
free
so this should never happened we need to investigate more why this
append
Best Regards,
J.
On Aug 20, 2014, at 6:07 AM, Gaël PORTAY gael.por...@gmail.com wrote:
Shutdown properly the timer
On Aug 1, 2014, at 12:48 AM, Alexandre Belloni
wrote:
>
> On 01/08/2014 at 00:10:05 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
>>>>> While this solves the particular issue Jiří is seeing, this will not
>>>>> solve the case where PA14 (CS0)
On Jul 31, 2014, at 11:59 PM, Alexandre Belloni
wrote:
> On 29/07/2014 at 10:00:17 +0200, Boris Brezillon wrote :
>> Hi Alexandre,
>>
>>> While this solves the particular issue Jiří is seeing, this will not
>>> solve the case where PA14 (CS0) is not used by the spi driver at all. It
>>> will
On Jul 31, 2014, at 11:59 PM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On 29/07/2014 at 10:00:17 +0200, Boris Brezillon wrote :
Hi Alexandre,
While this solves the particular issue Jiří is seeing, this will not
solve the case where PA14 (CS0) is not used by the spi
On Aug 1, 2014, at 12:48 AM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On 01/08/2014 at 00:10:05 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
While this solves the particular issue Jiří is seeing, this will not
solve the case where PA14 (CS0) is not used by the spi
On 11:06 Fri 04 Jul , Maxime Ripard wrote:
> On Fri, Jul 04, 2014 at 09:14:43AM +0200, Boris BREZILLON wrote:
> > On Fri, 4 Jul 2014 11:08:20 +0800
> > Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> > >
> > > On Jul 3, 2014, at 10:59 PM, Maxime Ripa
On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
>
> Atmel SoCs have one or multiple RAM controllers that need one or multiple
> clocks
> to run.
> This driver handle those clocks.
>
> Signed-off-by: Alexandre Belloni
> ---
> .../devicetree/bindings/arm/atmel-at91.txt | 1 +
>
On 16:52 Thu 03 Jul , Maxime Ripard wrote:
> Hi,
>
> On Thu, Jul 03, 2014 at 10:29:58PM +0800, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > no do this at SoC level
>
> Since it has to be done at init_machine, I don't see any other easy
> way to do this at the S
On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
>
> Define the available clock for mprddr and take both mpddr_clk and ddrck in the
> ram controller driver.
>
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/boot/dts/sama5d3.dtsi | 9 -
> 1 file changed, 8 insertions(+), 1
On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
Define the available clock for mprddr and take both mpddr_clk and ddrck in the
ram controller driver.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/boot/dts/sama5d3.dtsi | 9 -
1 file
On 16:52 Thu 03 Jul , Maxime Ripard wrote:
Hi,
On Thu, Jul 03, 2014 at 10:29:58PM +0800, Jean-Christophe PLAGNIOL-VILLARD
wrote:
no do this at SoC level
Since it has to be done at init_machine, I don't see any other easy
way to do this at the SoC level.
What is your suggestion
On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
Atmel SoCs have one or multiple RAM controllers that need one or multiple
clocks
to run.
This driver handle those clocks.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
On 11:06 Fri 04 Jul , Maxime Ripard wrote:
On Fri, Jul 04, 2014 at 09:14:43AM +0200, Boris BREZILLON wrote:
On Fri, 4 Jul 2014 11:08:20 +0800
Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote:
On Jul 3, 2014, at 10:59 PM, Maxime Ripard
maxime.rip...@free
On Jul 3, 2014, at 10:59 PM, Maxime Ripard
wrote:
> On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -0,0 +1,202 @@
>>> +/*
>>> + * Atmel AT91 SAM9 SoCs reset code
On Jul 3, 2014, at 10:59 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD
wrote:
+++ b/drivers/power/reset/at91-reset.c
@@ -0,0 +1,202 @@
+/*
+ * Atmel AT91 SAM9 SoCs reset code
+ *
+ * Copyright (C
On Jul 3, 2014, at 10:59 PM, Maxime Ripard
wrote:
> On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -0,0 +1,202 @@
>>> +/*
>>> + * Atmel AT91 SAM9 SoCs reset code
no do this at SoC level
Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard
wrote:
>
> Make every board call the register_devices callback so that the devices
> declared by the SoC are registered.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/mach-at91/board-afeb-9260v1.c | 2
patch 4 and 18 what is the difference?
Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard
wrote:
>
> Adapt the ramc mapping code to handle multiple ram controllers in the DT.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/mach-at91/setup.c | 26 ++
> 1
NACK
On Jul 3, 2014, at 10:14 PM, Maxime Ripard
wrote:
>
> Implement the reset behaviour of the various AT91 SoCS in drivers/power/reset.
>
> It used to be (and still is) located in arch/arm/mach-at91, and in order to
> preserve bisectability is not removed yet, but every board should be
On Jul 3, 2014, at 10:14 PM, Maxime Ripard
wrote:
>
> Add a driver to handle the shutdown of the Atmel SoCs. This code used to be
> (and still is) in arch/arm/mach-at91. We didn't removed it yet so that we can
> convert all the boards to using this driver, before removing it entirely in a
>
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
Add a driver to handle the shutdown of the Atmel SoCs. This code used to be
(and still is) in arch/arm/mach-at91. We didn't removed it yet so that we can
convert all the boards to using this driver, before
NACK
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
Implement the reset behaviour of the various AT91 SoCS in drivers/power/reset.
It used to be (and still is) located in arch/arm/mach-at91, and in order to
preserve bisectability is not removed yet,
patch 4 and 18 what is the difference?
Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
Adapt the ramc mapping code to handle multiple ram controllers in the DT.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
no do this at SoC level
Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
Make every board call the register_devices callback so that the devices
declared by the SoC are registered.
Signed-off-by: Maxime Ripard
On Jul 3, 2014, at 10:59 PM, Maxime Ripard maxime.rip...@free-electrons.com
wrote:
On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD
wrote:
+++ b/drivers/power/reset/at91-reset.c
@@ -0,0 +1,202 @@
+/*
+ * Atmel AT91 SAM9 SoCs reset code
+ *
+ * Copyright (C
On May 20, 2014, at 1:50 PM, Olof Johansson wrote:
>
> On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote:
>> Arnd, Olof, Kevin,
>>
>> More DT material for AT91. Some fixes that apply on what was merged for 3.15
>> but that are not very critical.
>> The other patches are feature
On May 20, 2014, at 1:50 PM, Olof Johansson o...@lixom.net wrote:
On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote:
Arnd, Olof, Kevin,
More DT material for AT91. Some fixes that apply on what was merged for 3.15
but that are not very critical.
The other patches are feature
On May 15, 2014, at 4:34 PM, Paul Bolle wrote:
>
> In v2.6.25 code was added for an Image Sensor Interface (ISI) for
> AT91SAM9263. That code depended on the Kconfig macro
> CONFIG_VIDEO_AT91_ISI and its MODULE variant. The related Kconfig symbol
> has never been added to the tree. The net
On May 15, 2014, at 4:34 PM, Paul Bolle pebo...@tiscali.nl wrote:
In v2.6.25 code was added for an Image Sensor Interface (ISI) for
AT91SAM9263. That code depended on the Kconfig macro
CONFIG_VIDEO_AT91_ISI and its MODULE variant. The related Kconfig symbol
has never been added to the
On Apr 16, 2014, at 5:40 PM, Daeseok Youn wrote:
>
> The spec->modedb can be NULL by fb_create_modedb().
>
> And also smatch says:
> drivers/video/fbdev/core/fbmon.c:975 fb_edid_to_monspecs() error:
> potential null dereference 'specs->modedb'.
> (fb_create_modedb returns null)
>
>
On Apr 16, 2014, at 5:40 PM, Daeseok Youn daeseok.y...@gmail.com wrote:
The spec-modedb can be NULL by fb_create_modedb().
And also smatch says:
drivers/video/fbdev/core/fbmon.c:975 fb_edid_to_monspecs() error:
potential null dereference 'specs-modedb'.
(fb_create_modedb returns null)
On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
> This patch adds support for the Device Tree on a sam9261-based platform
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> arch/arm/boot/dts/at91sam9261.dtsi | 740
> +
> arch/arm/mach-at91/at91sam9261.c |
On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
> This patch implements a DTS to boot a at91sam9261ek with a dt-enabled
> kernel (at91_dt_defconfig).
> supported features are:
> * dbgu
> * lcdc
> * usb host
> * usb gadget,
> * spi dataflash
> * nand flash
> * touchscreen
> * leds
> * user
On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
This patch implements a DTS to boot a at91sam9261ek with a dt-enabled
kernel (at91_dt_defconfig).
supported features are:
* dbgu
* lcdc
* usb host
* usb gadget,
* spi dataflash
* nand flash
* touchscreen
* leds
* user buttons
In
On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
This patch adds support for the Device Tree on a sam9261-based platform
Signed-off-by: Jean-Jacques Hiblot jjhib...@traphandler.com
---
arch/arm/boot/dts/at91sam9261.dtsi | 740
+
On Mar 10, 2014, at 10:37 PM, Nicolas Ferre wrote:
> From: Boris BREZILLON
>
> On the newly introduced sama5d36, Gigabit and 10/100 Ethernet network
> interfaces are probed in a different order than for the sama5d35.
> Moreover, users are accustomed to this order in bootloaders and backports
On Mar 11, 2014, at 2:54 PM, Yang, Wenyou wrote:
>
>
>> -Original Message-----
>> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
>> Sent: Tuesday, March 11, 2014 12:16 PM
>> To: Yang, Wenyou
>> Cc: Jean-Christophe PLAGNIOL-VILLA
On Mar 11, 2014, at 2:54 PM, Yang, Wenyou wenyou.y...@atmel.com wrote:
-Original Message-
From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
Sent: Tuesday, March 11, 2014 12:16 PM
To: Yang, Wenyou
Cc: Jean-Christophe PLAGNIOL-VILLARD; mark.rutl...@arm.com
On Mar 10, 2014, at 10:37 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
From: Boris BREZILLON b.brezillon@gmail.com
On the newly introduced sama5d36, Gigabit and 10/100 Ethernet network
interfaces are probed in a different order than for the sama5d35.
Moreover, users are accustomed
On Mar 11, 2014, at 9:28 AM, Yang, Wenyou wrote:
> Hi JC,
>
>> -Original Message-
>> From: Yang, Wenyou
>> Sent: Wednesday, March 05, 2014 1:32 PM
>> To: Jean-Christophe PLAGNIOL-VILLARD
>> Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; &
On Mar 11, 2014, at 9:28 AM, Yang, Wenyou wenyou.y...@atmel.com wrote:
Hi JC,
-Original Message-
From: Yang, Wenyou
Sent: Wednesday, March 05, 2014 1:32 PM
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; linux-arm-
ker
On Mar 5, 2014, at 9:53 AM, Wenyou Yang wrote:
> In order to support the pinctrl sleep state.
As I said before NACK
this is not the job of the pinctrl to describe gpio output or input state
Best Regards,
J.
>
> Signed-off-by: Wenyou Yang
> ---
> Hi Linus,
>
> The patch is based on branch:
On Mar 5, 2014, at 9:53 AM, Wenyou Yang wenyou.y...@atmel.com wrote:
In order to support the pinctrl sleep state.
As I said before NACK
this is not the job of the pinctrl to describe gpio output or input state
Best Regards,
J.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
---
Hi
On 15:37 Fri 07 Feb , Nicolas Ferre wrote:
> On 07/02/2014 09:01, Jean-Christophe PLAGNIOL-VILLARD :
> > On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
> >> Add DT file for new SAMA5D3 Xpained board.
> >> This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
>
On 17:36 Fri 07 Feb , Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> This is a first "fixes" series for AT91 on 3.14.
> The content is only DT-related and quite boring.
> I took the opportunity of this early "fixes" pull-request to collect
> some Documentation patches that were lying around
On 10:06 Tue 21 Jan , Nicolas Ferre wrote:
> On 21/01/2014 09:12, Bo Shen :
> > Hi J,
> >
> > On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 11:39 Mon 20 Jan , Bo Shen wrote:
> >>> Hi J,
> >>>
> >>&
On 13:31 Thu 09 Jan , Jean-Jacques Hiblot wrote:
> The EBI/SMC external interface is used to access external peripherals (NAND
> and Ethernet controller in the case of sam9261ek). Different configurations
> and
> timings are required for those peripherals. This bus driver can be used to
>
On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
> Add DT file for new SAMA5D3 Xpained board.
> This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
>
> Signed-off-by: Nicolas Ferre
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233
On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
Add DT file for new SAMA5D3 Xpained board.
This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/Makefile | 1 +
On 13:31 Thu 09 Jan , Jean-Jacques Hiblot wrote:
The EBI/SMC external interface is used to access external peripherals (NAND
and Ethernet controller in the case of sam9261ek). Different configurations
and
timings are required for those peripherals. This bus driver can be used to
setup
On 10:06 Tue 21 Jan , Nicolas Ferre wrote:
On 21/01/2014 09:12, Bo Shen :
Hi J,
On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 11:39 Mon 20 Jan , Bo Shen wrote:
Hi J,
On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:59 Fri 17 Jan
On 17:36 Fri 07 Feb , Nicolas Ferre wrote:
Arnd, Olof, Kevin,
This is a first fixes series for AT91 on 3.14.
The content is only DT-related and quite boring.
I took the opportunity of this early fixes pull-request to collect
some Documentation patches that were lying around and I guess
On 15:37 Fri 07 Feb , Nicolas Ferre wrote:
On 07/02/2014 09:01, Jean-Christophe PLAGNIOL-VILLARD :
On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
Add DT file for new SAMA5D3 Xpained board.
This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
Signed-off-by: Nicolas Ferre nicolas.fe
1 - 100 of 612 matches
Mail list logo
