* RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Y.B. Lu @ 2016-11-08 6:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org, linux-mmc@vger.kernel.org,
ulf.hansson@linaro.org, Scott Wood, Mark Rutland,
Greg Kroah-Hartman, X.B. Xie, M.H. Lian,
linux-i2c@vger.kernel.org, linux-clk@vger.kernel.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Joerg Roedel, Claudiu Manoil,
devicetree@vger.kernel.org, Rob Herring
In-Reply-To: <1543282.vWjeo4ynTa@wuerfel>
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Tuesday, November 08, 2016 5:20 AM
> To: Y.B. Lu
> Cc: linuxppc-dev@lists.ozlabs.org; linux-mmc@vger.kernel.org;
> ulf.hansson@linaro.org; Scott Wood; Mark Rutland; Greg Kroah-Hartman; X.B.
> Xie; M.H. Lian; linux-i2c@vger.kernel.org; linux-clk@vger.kernel.org;
> Qiang Zhao; Russell King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> devicetree@vger.kernel.org; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Leo Li; iommu@lists.linux-foundation.org; Kumar
> Gala
> Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
>
> On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote:
> > >
> > > I don't see any of the contents of this header referenced by the soc
> > > driver any more. I think you can just drop this patch.
> > >
> >
> > [Lu Yangbo-B47093] This header file was included by guts.c.
> > The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
> >
> > This header file was for powerpc arch before. And this patch is to
> > made it as common header file for both ARM and PPC.
> > Sooner or later this is needed.
>
> Let's discuss it once we actually need the header then, ok?
[Lu Yangbo-B47093] As I said, this header file was included by guts.c in patch 4.
The guts driver used macro SVR_MAJ/SVR_MIN for calculation which were defined in this header file.
Did you suggest we dropped this patch and just calculated them in driver?
Thanks :)
>
> Arnd
^ permalink raw reply
* Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"
From: Greg Kroah-Hartman @ 2016-11-08 7:00 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linus Torvalds, Hans de Goede, Andrew Morton, Paul Burton,
Rob Herring, Frank Rowand, Thorsten Leemhuis, Tejun Heo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87h97ilrx0.fsf-W0DJWXSxmBNbyGPkN3NxC2scP1bn1w/D@public.gmane.org>
On Tue, Nov 08, 2016 at 11:46:35AM +1100, Michael Ellerman wrote:
> Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
>
> > This reverts commit 05fd007e4629 ("console: don't prefer first registered
> > if DT specifies stdout-path").
> >
> > The reverted commit changes existing behavior on which many ARM boards
> > rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> > both a video output and a serial console. Depending on whether the user
> > is using the device as a more regular computer; or as a headless device
> > we need to have the console on either one or the other.
> >
> > Many users rely on the kernel behavior of the console being present on
> > both outputs, before the reverted commit the console setup with no
> > console= kernel arguments on an ARM board which sets stdout-path in dt
> > would look like this:
> >
> > [root@localhost ~]# cat /proc/consoles
> > ttyS0 -W- (EC p a) 4:64
> > tty0 -WU (E p ) 4:1
> >
> > Where as after the reverted commit, it looks like this:
> >
> > [root@localhost ~]# cat /proc/consoles
> > ttyS0 -W- (EC p a) 4:64
> >
> > This commit reverts commit 05fd007e4629 ("console: don't prefer first
> > registered if DT specifies stdout-path") restoring the original behavior.
> >
> > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> This is also breaking various powerpc systems.
>
> Linus can you please merge this revert for 4.9 ?
I'll queue it up with other tty changes for 4.9-final.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-08 8:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vineet Gupta
In-Reply-To: <20161101200141.GF1506@mai>
> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> Sent: Tuesday, November 1, 2016 10:02 PM
...
>Assuming cpu0 and cpu1 are sibling, does
>taskset 0x1 time sleep 2 & taskset 0x2 time sleep 3
I will use 16,17 instead of 0,1
>give a correct result without a dmesg log ?
[root@192.168.8.2 /]$ [root@192.168.8.2 /]$ taskset 65536 time sleep 2 & taskset 131072 time sleep 3
real 0m 2.54s
user 0m 0.04s
sys 0m 0.14s
real 0m 3.47s
user 0m 0.00s
sys 0m 0.15s
[1]+ Done taskset 65536 time sleep 2
Seem OK to me.
> Can you give the content of the /proc/timer_list ?
[root@192.168.8.2 /]$ cat /proc/timer_list
Timer List Version: v0.8
HRTIMER_MAX_CLOCK_BASES: 4
now at 2421277626774 nsecs
cpu: 0
clock 0:
.base: 9fccb540
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
.offset: 0 nsecs
active timers:
#0: <9fccb69c>, tick_sched_timer, S:01
# expires at 2421140000000-2421140000000 nsecs [in -137626774 to -137626774 nsecs]
clock 1:
.base: 9fccb560
.index: 1
.resolution: 1 nsecs
.get_time: ktime_get_real
.offset: 0 nsecs
active timers:
clock 2:
.base: 9fccb580
.index: 2
.resolution: 1 nsecs
.get_time: ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 3:
.base: 9fccb5a0
.index: 3
.resolution: 1 nsecs
.get_time: ktime_get_clocktai
.offset: 0 nsecs
active timers:
.expires_next : 2421140000000 nsecs
.hres_active : 1
.nr_events : 615427
.nr_retries : 10052
.nr_hangs : 37
.max_hang_time : 682411010
.nohz_mode : 2
.last_tick : 0 nsecs
.tick_stopped : 0
.idle_jiffies : 0
.idle_calls : 0
.idle_sleeps : 0
.idle_entrytime : 2421131605769 nsecs
.idle_waketime : 0 nsecs
.idle_exittime : 0 nsecs
.idle_sleeptime : 1900903609165 nsecs
.iowait_sleeptime: 0 nsecs
.last_jiffies : 0
.next_timer : 0
.idle_expires : 0 nsecs
jiffies: 212114
cpu: 16
clock 0:
.base: 9fcd7540
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
.offset: 0 nsecs
active timers:
clock 1:
.base: 9fcd7560
.index: 1
.resolution: 1 nsecs
.get_time: ktime_get_real
.offset: 0 nsecs
active timers:
clock 2:
.base: 9fcd7580
.index: 2
.resolution: 1 nsecs
.get_time: ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 3:
.base: 9fcd75a0
.index: 3
.resolution: 1 nsecs
.get_time: ktime_get_clocktai
.offset: 0 nsecs
active timers:
.expires_next : 9223372036854775807 nsecs
.hres_active : 1
.nr_events : 18
.nr_retries : 1
.nr_hangs : 0
.max_hang_time : 0
.nohz_mode : 2
.last_tick : 2410120000000 nsecs
.tick_stopped : 1
.idle_jiffies : 211017
.idle_calls : 27
.idle_sleeps : 27
.idle_entrytime : 2410189597725 nsecs
.idle_waketime : 2410189342725 nsecs
.idle_exittime : 2410110197721 nsecs
.idle_sleeptime : 2408852044732 nsecs
.iowait_sleeptime: 0 nsecs
.last_jiffies : 211019
.next_timer : 9223372036854775807
.idle_expires : 9223372036854775807 nsecs
jiffies: 212114
cpu: 17
clock 0:
.base: 9fce3540
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
.offset: 0 nsecs
active timers:
clock 1:
.base: 9fce3560
.index: 1
.resolution: 1 nsecs
.get_time: ktime_get_real
.offset: 0 nsecs
active timers:
clock 2:
.base: 9fce3580
.index: 2
.resolution: 1 nsecs
.get_time: ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 3:
.base: 9fce35a0
.index: 3
.resolution: 1 nsecs
.get_time: ktime_get_clocktai
.offset: 0 nsecs
active timers:
.expires_next : 9223372036854775807 nsecs
.hres_active : 1
.nr_events : 22
.nr_retries : 1
.nr_hangs : 0
.max_hang_time : 0
.nohz_mode : 2
.last_tick : 2412120000000 nsecs
.tick_stopped : 1
.idle_jiffies : 211212
.idle_calls : 32
.idle_sleeps : 32
.idle_entrytime : 2412123353729 nsecs
.idle_waketime : 2412123049733 nsecs
.idle_exittime : 2412110161733 nsecs
.idle_sleeptime : 2410832354720 nsecs
.iowait_sleeptime: 0 nsecs
.last_jiffies : 211213
.next_timer : 9223372036854775807
.idle_expires : 9223372036854775807 nsecs
jiffies: 212114
Tick Device: mode: 1
Per CPU device: 0
Clock Event Device: ARC Timer0
max_delta_ns: 51539607733
min_delta_ns: 1000
mult: 178956970
shift: 31
mode: 3
next_event: 2421140000000 nsecs
set_next_event: arc_clkevent_set_next_event
periodic: arc_clkevent_set_periodic
event_handler: hrtimer_interrupt
retries: 0
Tick Device: mode: 1
Per CPU device: 16
Clock Event Device: ARC Timer0
max_delta_ns: 51539607733
min_delta_ns: 1000
mult: 178956970
shift: 31
mode: 3
next_event: 9223372036854775807 nsecs
set_next_event: arc_clkevent_set_next_event
periodic: arc_clkevent_set_periodic
event_handler: hrtimer_interrupt
retries: 2
Tick Device: mode: 1
Per CPU device: 17
Clock Event Device: ARC Timer0
max_delta_ns: 51539607733
min_delta_ns: 1000
mult: 178956970
shift: 31
mode: 3
next_event: 9223372036854775807 nsecs
set_next_event: arc_clkevent_set_next_event
periodic: arc_clkevent_set_periodic
event_handler: hrtimer_interrupt
retries: 2
-Noam
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-08 8:35 UTC (permalink / raw)
To: Radosław Pietrzyk
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <CAFvLkMQxvo=2Ak033n2XkPgdDfU5DLCMF7dj487QFB0e7WceCQ@mail.gmail.com>
Hi Radosław
Many thanks for reviewing.
On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>> +static struct clk_hw *clk_register_pll_div(const char *name,
>> + const char *parent_name, unsigned long flags,
>> + void __iomem *reg, u8 shift, u8 width,
>> + u8 clk_divider_flags, const struct clk_div_table *table,
>> + struct clk_hw *pll_hw, spinlock_t *lock)
>> +{
>> + struct stm32f4_pll_div *pll_div;
>> + struct clk_hw *hw;
>> + struct clk_init_data init;
>> + int ret;
>> +
>> + /* allocate the divider */
>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>> + if (!pll_div)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + init.name = name;
>> + init.ops = &stm32f4_pll_div_ops;
>> + init.flags = flags;
> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
> should have CLK_SET_RATE_GATE flag and we can get rid of custom
> divider ops.
I don't want to offer the possibility to change the vco clock through
the divisor of the pll (only by a boot-loader or by DT).
e.g. if i make a set rate on lcd-tft clock, i don't want to change the
SAI frequencies.
I used same structure for internal divisors of the pll (p, q, r) and for
post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
These divisors are similar because we have to switch off the pll before
changing the rate.
>
>
>> -static void stm32f4_rcc_register_pll(const char *hse_clk, const char *hsi_clk)
>> +
>> +static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
>> + const struct stm32f4_pll_data *data, spinlock_t *lock)
>> {
>> - unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
>> + struct stm32f4_pll *pll;
>> + struct clk_init_data init = { NULL };
>> + void __iomem *reg;
>> + struct clk_hw *pll_hw;
>> + int ret;
>> +
>> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
>> + if (!pll)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + init.name = data->vco_name;
>> + init.ops = &stm32f4_pll_gate_ops;
>> + init.flags = CLK_IGNORE_UNUSED;
> CLK_SET_RATE_GATE here
>
> Moreover why not having VCO as a composite clock from gate and mult ?
Yes, that sounds a good idea.
> According to docs SAI VCO (don't know about I2S ) must be within
> certain range so clk_set_rate_range should be somewhere.
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-08 8:52 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <ebadfacf-73fb-01a6-791a-324daad5e695@st.com>
2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
> Hi Radosław
>
> Many thanks for reviewing.
>
> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>
>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>> + const char *parent_name, unsigned long flags,
>>> + void __iomem *reg, u8 shift, u8 width,
>>> + u8 clk_divider_flags, const struct clk_div_table *table,
>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>> +{
>>> + struct stm32f4_pll_div *pll_div;
>>> + struct clk_hw *hw;
>>> + struct clk_init_data init;
>>> + int ret;
>>> +
>>> + /* allocate the divider */
>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>> + if (!pll_div)
>>> + return ERR_PTR(-ENOMEM);
>>> +
>>> + init.name = name;
>>> + init.ops = &stm32f4_pll_div_ops;
>>> + init.flags = flags;
>>
>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>> divider ops.
>
> I don't want to offer the possibility to change the vco clock through the
> divisor of the pll (only by a boot-loader or by DT).
>
> e.g. if i make a set rate on lcd-tft clock, i don't want to change the SAI
> frequencies.
>
> I used same structure for internal divisors of the pll (p, q, r) and for
> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>
> These divisors are similar because we have to switch off the pll before
> changing the rate.
>
But changing pll and lcd dividers only may not be enough for getting
very specific pixelclocks and that might require changing the VCO
frequency itself. The rest of the SAI tree should be recalculated
then.
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Peter De Schrijver @ 2016-11-08 8:54 UTC (permalink / raw)
To: Jon Hunter
Cc: devicetree, Stephen Warren, Paul Kocialkowski, linux-kernel,
Thierry Reding, linux-tegra, Alexandre Courbot, linux-arm-kernel
In-Reply-To: <13e7ff98-8bc2-ccf7-94bb-4e1d3c61b20d@nvidia.com>
On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>
> On 07/11/16 13:28, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> >
> > On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> >> Nyan boards only have host USB ports (2 external, 1 internal), there is
> >> no OTG-enabled connector.
> >>
> >> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >> ---
> >> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Where is this information coming from? I don't have one of the Nyans
> > myself, but one of the Tegra132 devices I have, which I think was
> > derived from one of the Nyans uses one of the external host ports as
> > forced recovery port, for which it would need OTG.
> >
> > I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> > In that case I think one of the ports must be OTG.
>
> It is true that the port on the back on the nyan-big can be used with
> recovery mode. I was thinking that this is not a true OTG port as it is
> just a 4-pin type A socket and does not have an ID pin. Thinking some
> more about this the USB spec does include a "Host Negotiation Protocol
> (HNP)" that allows a host and device to swap roles and so keeping it as
> OTG seems valid afterall.
I don't think the bootrom implements that though. I expect recovery mode
to just program the controller in device mode, without performing any
negotiation.
Peter.
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Paul Kocialkowski @ 2016-11-08 9:09 UTC (permalink / raw)
To: Peter De Schrijver, Jon Hunter
Cc: Thierry Reding, devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Alexandre Courbot,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161108085420.GG2478-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]
Le mardi 08 novembre 2016 à 10:54 +0200, Peter De Schrijver a écrit :
> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
> >
> > On 07/11/16 13:28, Thierry Reding wrote:
> > > * PGP Signed by an unknown key
> > >
> > > On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> > > > Nyan boards only have host USB ports (2 external, 1 internal), there is
> > > > no OTG-enabled connector.
> > > >
> > > > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> > > > ---
> > > > arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Where is this information coming from? I don't have one of the Nyans
> > > myself, but one of the Tegra132 devices I have, which I think was
> > > derived from one of the Nyans uses one of the external host ports as
> > > forced recovery port, for which it would need OTG.
> > >
> > > I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> > > In that case I think one of the ports must be OTG.
> >
> > It is true that the port on the back on the nyan-big can be used with
> > recovery mode. I was thinking that this is not a true OTG port as it is
> > just a 4-pin type A socket and does not have an ID pin. Thinking some
> > more about this the USB spec does include a "Host Negotiation Protocol
> > (HNP)" that allows a host and device to swap roles and so keeping it as
> > OTG seems valid afterall.
>
> I don't think the bootrom implements that though. I expect recovery mode
> to just program the controller in device mode, without performing any
> negotiation.
That would make sense.
However, if there's a way (even not implemented yet, but a possible way) to have
the kernel configure this port as USB device instead of host dynamically (e.g.
without changing this bit in the dts), then I think it makes sense to keep the
OTG marking and drop this patch.
After all, switching to USB device mode doesn't necessarily have to come from
the ID pin.
--
Paul Kocialkowski, developer of free digital technology at the lower levels
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
From: Hans de Goede @ 2016-11-08 9:12 UTC (permalink / raw)
To: Paul Burton
Cc: Linus Torvalds, Andrew Morton, Rob Herring, Frank Rowand,
Thorsten Leemhuis, Greg Kroah-Hartman, Tejun Heo, devicetree,
linux-kernel
In-Reply-To: <3421375.fR4RSn7eD9@np-p-burton>
Hi,
On 07-11-16 18:16, Paul Burton wrote:
> Hi Hans,
>
> On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
>>> What I see in my systems, and what 05fd007e4629 ("console: don't prefer
>>> first registered if DT specifies stdout-path") addressed, is that if
>>> there are for example 2 UARTs uart0 & uart1 that are probed in that order
>>> and stdout-path indicates that we should use uart1 we wind up essentially
>>> ignoring it because>
>>> the ordering of the relevant calls goes:
>>> - of_console_check() for uart0
>>> - add_preferred_console() for uart0
>>> - register_console() for uart0
>>> - of_console_check() for uart1
>>> - add_preferred_console() for uart1
>>> - register_console() for uart1
>>>
>>> Since of_check_console() doesn't get called for uart1 until after uart0
>>> has
>>> been probed, we don't add an entry for it to the console_cmdline array
>>> until after register_console() has already decided to enable uart0
>>> because preferred_console == -1.
>>>
>>> I'm not the only one seeing this oddity either, for example see the
>>> discussion on this patch:
>>>
>>> https://patchwork.kernel.org/patch/9263753/
>>>
>>> By simply reverting my patch you restore us to a position where so far as
>>> I
>>> can see we simply do not honor stdout-path for the real kernel console.
>>
>> As said before, we do still honor it, but in your probe example we also get
>> a (second) serial console on uart0, where as you only want one on uart1.
>
> ...but don't we only support one console per type of device? That's what
> Documentation/serial-console.txt says anyway, which means having a console on
> both uart0 & uart1 does not work. I could live with having console output on
> an extra UART, but that's not what I was seeing when I wrote this patch.
Ah yes, you're probably right about that.
>> So I see a few possible solutions here:
>>
>> 1) Do a new version of your patch which changes the "&&
>> !of_specified_console" check to "&& (newcon == tty0 ||
>> !of_specified_console)", then we would still always register tty0 (as long
>> as it gets registered first, just like now) and we would not register uart0
>> in your above example, note the "newcon == tty0" check in my example is
>> pseudo-code. I would be happy to try out such a patch
>>
>> 2) Add a new dt property to enable the new behavior you seek
>>
>> I'm myself tending towards 1 as a better solution: treat tty0 special,
>> because some existing setups rely on it always being registered as a
>> console even if stdout-path is specified and otherwise always honor
>> stdout-path.
>>
>> Regards,
>>
>> Hans
>
> That does feel a little hack-ish to me though... I don't like the reliance on
> probe ordering, nor special casing tty0 in general.
Given that we've just got a "me too" reply from the ppc side of things,
it seems that in reality people have been relying on probe ordering here
for a long time now. IMHO tty0 is special, so it does make sense that it
always gets probed first (*) and it does make sense to handle it special.
*) Even though that seems to be more how things work (an implicit thing)
rather then explicit.
> In any case I don't think I have the time to unpick all this at the moment, so
> I suggest we go ahead with your revert for now & I'll revisit the system I was
> working on when I find the time.
Ok.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: Felipe Balbi @ 2016-11-08 9:12 UTC (permalink / raw)
To: John Youn
In-Reply-To: <e99e9d8df77884671f94734109a1a8d76a0222c1.1478558343.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2211 bytes --]
Hi,
John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> Add a vendor prefix and make the name more consistent by renaming it to
> "snps,gadget-dma-enable".
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
> arch/arm/boot/dts/rk3036.dtsi | 2 +-
> arch/arm/boot/dts/rk3288.dtsi | 2 +-
> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
> drivers/usb/dwc2/params.c | 9 ++++++++-
> drivers/usb/dwc2/pci.c | 2 +-
> 8 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 9472111..389a461 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
> - dr_mode: shall be one of "host", "peripheral" and "otg"
> Refer to usb/generic.txt
> - snps,host-dma-disable: disable host DMA mode.
> -- g-use-dma: enable dma usage in gadget driver.
> +- snps,gadget-dma-enable: enable gadget DMA mode.
I don't see why you even have this binding. Looking through the code,
you have:
#define GHWCFG2_SLAVE_ONLY_ARCH 0
#define GHWCFG2_EXT_DMA_ARCH 1
#define GHWCFG2_INT_DMA_ARCH 2
void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
{
int valid = 1;
if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
valid = 0;
if (val < 0)
valid = 0;
if (!valid) {
if (val >= 0)
dev_err(hsotg->dev,
"%d invalid for dma_enable parameter. Check HW configuration.\n",
val);
val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
}
hsotg->core_params->dma_enable = val;
}
which seems to hint that DMA support is discoverable. If there is DMA,
why would disable it?
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
[-- Attachment #2: Type: text/plain, Size: 200 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH 03/30] usb: dwc2: gadget: Add descriptor DMA binding
From: Felipe Balbi @ 2016-11-08 9:14 UTC (permalink / raw)
To: John Youn; +Cc: Vahram Aharonyan
In-Reply-To: <e0d302ebcbad32242da84894c173b743b9199f71.1478558343.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> From: Vahram Aharonyan <vahrama-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>
> Add the devicetree binding to enable descriptor DMA and read it in to
> the corresponding parameter during probe.
>
> Signed-off-by: Vahram Aharonyan <vahrama-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
> drivers/usb/dwc2/core.h | 4 ++++
> drivers/usb/dwc2/gadget.c | 11 +++++++++++
> drivers/usb/dwc2/params.c | 4 ++++
> 4 files changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 389a461..1db9c37 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -27,6 +27,7 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
> Refer to usb/generic.txt
> - snps,host-dma-disable: disable host DMA mode.
> - snps,gadget-dma-enable: enable gadget DMA mode.
> +- snps,gadget-dma-desc-enable: enable gadget DMA descriptor mode.
seems to be discoverable as well:
#define GHWCFG4_DESC_DMA_DYN (1 << 31)
#define GHWCFG4_DESC_DMA (1 << 30)
care to comment?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [RESEND][PATCH 0/6] Add NXP LS2088A platform support
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini
This patchset adds support for the QorIQ LS2088A SoC
LS2088A SoC is similar to LS2080A SoC with a few differences like
it has A72 cores.
Supported targets are QDS and RDB boards. The updates
include binding updates, and addition of the ls2088a
device dtsi and dts files.
Abhimanyu Saini (6):
dt-bindings: arm: Update bindings for LS2088A targets
dt-bindings: pci: Update bindings for LS2088A
dt-bindings: mtd: fsl-quadspi: Update qspi bindings for LS2088A
dt-bindings: spi: Update dspi bindings for LS2088A
dt-bindings: gpio: Update gpio bindings for LS2088A
arm64: Add DTS support for FSL's LS2088A SoC
Documentation/devicetree/bindings/arm/fsl.txt | 7 +
.../devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
.../devicetree/bindings/mtd/fsl-quadspi.txt | 4 +-
.../devicetree/bindings/pci/layerscape-pci.txt | 5 +-
.../devicetree/bindings/spi/spi-fsl-dspi.txt | 3 +-
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 211 +++++++
arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 166 +++++
arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 703 +++++++++++++++++++++
9 files changed, 1096 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RESEND][PATCH 1/6] dt-bindings: arm: Update bindings for LS2088A targets
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Add compatible strings for LS2088A RDB and QDS board.
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/arm/fsl.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index d6ee9c6..cad97d2 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -179,3 +179,10 @@ LS2080A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
+LS2088A ARMv8 based QDS Board
+Required root node properties:
+ - compatible = "fsl,ls2088a-qds", "fsl,ls2088a"
+
+LS2088A ARMv8 based RDB Board
+Required root node properties:
+ - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a"
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND][PATCH 2/6] dt-bindings: pci: Update bindings for LS2088A
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55..ff32669 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -12,9 +12,8 @@ which can allow determining the underlying DesignWare PCIe controller version
information.
Required properties:
-- compatible: should contain the platform identifier such as:
- "fsl,ls1021a-pcie", "snps,dw-pcie"
- "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+- compatible: should be: "fsl,<chip>-pcie", "snps,dw-pcie".
+ <chip> can be: ls1021a, ls2080a, ls2088a
- reg: base addresses and lengths of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND][PATCH 3/6] dt-bindings: mtd: fsl-quadspi: Update qspi bindings for LS2088A
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index c34aa6f..2f95a8f 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -5,8 +5,8 @@ Required properties:
"fsl,imx7d-qspi", "fsl,imx6ul-qspi",
"fsl,ls1021a-qspi"
or
- "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
- "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
+ "fsl,<chip>-qspi", "fsl,ls1021a-qspi"
+ <chip> can be: ls2080a, ls2088a, ls1043a
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND][PATCH 4/6] dt-bindings: spi: Update dspi bindings for LS2088A
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index ff5893d..0870660 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -4,7 +4,8 @@ Required properties:
- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
"fsl,ls2085a-dspi"
or
- "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
+ "fsl,<chip>-dspi" followed by "fsl,ls2085a-dspi",
+ <chip> can be: ls2080a, ls2088a
- reg : Offset and length of the register set for the device
- interrupts : Should contain SPI controller interrupt
- clocks: from common clock binding: handle to dspi clock.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND][PATCH 5/6] dt-bindings: gpio: Update gpio bindings for LS2088A
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 4b6cc63..9b1be49 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a.
+ ls1021a, ls1043a, ls2080a, ls2088a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Abhimanyu Saini @ 2016-11-08 9:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1478597664-14799-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
This patch adds the device tree support for FSL LS2088A SoC based on
ARMv8 architecture.
Following levels of DTSI/DTS files have been created for the LS2088A
SoC family:
- fsl-ls2088a.dtsi:
DTS-Include file for FSL LS2088A SoC.
- fsl-ls2088a-qds.dts:
DTS file for FSL LS2088A QDS board.
- fsl-ls2088a-rdb.dts:
DTS file for FSL LS2088A RDB board.
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 211 +++++++
arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 166 +++++
arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 703 ++++++++++++++++++++++
4 files changed, 1082 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 6602718..fa3d66e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -5,6 +5,8 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
new file mode 100644
index 0000000..2b8d9f3
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
@@ -0,0 +1,211 @@
+/*
+ * Device Tree file for Freescale LS2088A QDS Board.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "fsl-ls2088a.dtsi"
+
+/ {
+ model = "Freescale Layerscape 2088A QDS Board";
+ compatible = "fsl,ls2088a-qds", "fsl,ls2088a";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ };
+
+};
+
+&esdhc {
+ status = "okay";
+};
+
+&ifc {
+ status = "okay";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x5 0x80000000 0x08000000
+ 0x2 0x0 0x5 0x30000000 0x00010000
+ 0x3 0x0 0x5 0x20000000 0x00010000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ cpld@3,0 {
+ reg = <0x3 0x0 0x10000>;
+ compatible = "fsl,ls2088aqds-fpga", "fsl,fpga-qixis";
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ pca9547@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x00>;
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x02>;
+
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <500>;
+ };
+
+ ina220@41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7481@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "disabled";
+};
+
+&i2c2 {
+ status = "disabled";
+};
+
+&i2c3 {
+ status = "disabled";
+};
+
+&dspi {
+ status = "okay";
+ dflash0: n25q128a {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <0>;
+ };
+ dflash1: sst25wf040b {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <1>;
+ };
+ dflash2: en25s64 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <2>;
+ };
+};
+
+&qspi {
+ status = "okay";
+ flash0: s25fl256s1@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+ flash2: s25fl256s1@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&sata0 {
+ status = "okay";
+};
+
+&sata1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
new file mode 100644
index 0000000..6d403bc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
@@ -0,0 +1,166 @@
+/*
+ * Device Tree file for Freescale LS2088A RDB Board.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "fsl-ls2088a.dtsi"
+
+/ {
+ model = "Freescale Layerscape 2088A RDB Board";
+ compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ };
+};
+
+&esdhc {
+ status = "okay";
+};
+
+&ifc {
+ status = "okay";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x5 0x80000000 0x08000000
+ 0x2 0x0 0x5 0x30000000 0x00010000
+ 0x3 0x0 0x5 0x20000000 0x00010000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ cpld@3,0 {
+ reg = <0x3 0x0 0x10000>;
+ compatible = "fsl,ls2088aqds-fpga", "fsl,fpga-qixis";
+ };
+
+};
+
+&i2c0 {
+ status = "okay";
+ pca9547@75 {
+ compatible = "nxp,pca9547";
+ reg = <0x75>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x01>;
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7481@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "disabled";
+};
+
+&i2c2 {
+ status = "disabled";
+};
+
+&i2c3 {
+ status = "disabled";
+};
+
+&dspi {
+ status = "okay";
+ dflash0: n25q512a {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <0>;
+ };
+};
+
+&qspi {
+ status = "disabled";
+};
+
+&sata0 {
+ status = "okay";
+};
+
+&sata1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
new file mode 100644
index 0000000..687ab5a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
@@ -0,0 +1,703 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-2088A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+ compatible = "fsl,ls2088a";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x0>;
+ clocks = <&clockgen 1 0>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x1>;
+ clocks = <&clockgen 1 0>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x100>;
+ clocks = <&clockgen 1 1>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x101>;
+ clocks = <&clockgen 1 1>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x200>;
+ clocks = <&clockgen 1 2>;
+ next-level-cache = <&cluster2_l2>;
+ };
+
+ cpu@201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x201>;
+ clocks = <&clockgen 1 2>;
+ next-level-cache = <&cluster2_l2>;
+ };
+
+ cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x300>;
+ clocks = <&clockgen 1 3>;
+ next-level-cache = <&cluster3_l2>;
+ };
+
+ cpu@301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x301>;
+ clocks = <&clockgen 1 3>;
+ next-level-cache = <&cluster3_l2>;
+ };
+
+ cluster0_l2: l2-cache0 {
+ compatible = "cache";
+ };
+
+ cluster1_l2: l2-cache1 {
+ compatible = "cache";
+ };
+
+ cluster2_l2: l2-cache2 {
+ compatible = "cache";
+ };
+
+ cluster3_l2: l2-cache3 {
+ compatible = "cache";
+ };
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "sysclk";
+ };
+
+ gic: interrupt-controller@6000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */
+ <0x0 0x06100000 0 0x100000>, /* GICR (RD_base + SGI_base) */
+ <0x0 0x0c0c0000 0 0x2000>, /* GICC */
+ <0x0 0x0c0d0000 0 0x1000>, /* GICH */
+ <0x0 0x0c0e0000 0 0x20000>; /* GICV */
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ interrupt-controller;
+ interrupts = <1 9 0x4>;
+
+ its: gic-its@6020000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ reg = <0x0 0x6020000 0 0x20000>;
+ };
+ };
+
+ reboot {
+ compatible ="syscon-reboot";
+ regmap = <&rstcr>;
+ offset = <0x0>;
+ mask = <0x2>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
+ <1 14 0x8>, /* Physical Non-Secure PPI, active-low */
+ <1 11 0x8>, /* Virtual PPI, active-low */
+ <1 10 0x8>; /* Hypervisor PPI, active-low */
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = <1 7 0x8>; /* PMU PPI, Level low type */
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ rstcr: syscon@1e60000 {
+ compatible = "fsl,ls2088a-rstcr", "fsl,ls2080a-rstcr",
+ "syscon";
+ reg = <0x0 0x1e60000 0x0 0x4>;
+ };
+
+ clockgen: clocking@1300000 {
+ compatible = "fsl,ls2088a-clockgen";
+ reg = <0 0x1300000 0 0xa0000>;
+ #clock-cells = <2>;
+ clocks = <&sysclk>;
+ };
+
+ serial0: serial@21c0500 {
+ compatible = "fsl,ns16550", "ns16550a";
+ reg = <0x0 0x21c0500 0x0 0x100>;
+ clocks = <&clockgen 4 3>;
+ interrupts = <0 32 0x4>; /* Level high type */
+ };
+
+ serial1: serial@21c0600 {
+ compatible = "fsl,ns16550", "ns16550a";
+ reg = <0x0 0x21c0600 0x0 0x100>;
+ clocks = <&clockgen 4 3>;
+ interrupts = <0 32 0x4>; /* Level high type */
+ };
+
+ cluster1_core0_watchdog: wdt@c000000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc000000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster1_core1_watchdog: wdt@c010000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc010000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster2_core0_watchdog: wdt@c100000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc100000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster2_core1_watchdog: wdt@c110000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc110000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster3_core0_watchdog: wdt@c200000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc200000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster3_core1_watchdog: wdt@c210000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc210000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster4_core0_watchdog: wdt@c300000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc300000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster4_core1_watchdog: wdt@c310000 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc310000 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ fsl_mc: fsl-mc@80c000000 {
+ compatible = "fsl,qoriq-mc";
+ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
+ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
+ msi-parent = <&its>;
+ #address-cells = <3>;
+ #size-cells = <1>;
+
+ /*
+ * Region type 0x0 - MC portals
+ * Region type 0x1 - QBMAN portals
+ */
+ ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
+ 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
+
+ /*
+ * Define the maximum number of MACs present on the SoC.
+ */
+ dpmacs {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpmac1: dpmac@1 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x1>;
+ };
+
+ dpmac2: dpmac@2 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x2>;
+ };
+
+ dpmac3: dpmac@3 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x3>;
+ };
+
+ dpmac4: dpmac@4 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x4>;
+ };
+
+ dpmac5: dpmac@5 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x5>;
+ };
+
+ dpmac6: dpmac@6 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x6>;
+ };
+
+ dpmac7: dpmac@7 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x7>;
+ };
+
+ dpmac8: dpmac@8 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x8>;
+ };
+
+ dpmac9: dpmac@9 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x9>;
+ };
+
+ dpmac10: dpmac@a {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xa>;
+ };
+
+ dpmac11: dpmac@b {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xb>;
+ };
+
+ dpmac12: dpmac@c {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xc>;
+ };
+
+ dpmac13: dpmac@d {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xd>;
+ };
+
+ dpmac14: dpmac@e {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xe>;
+ };
+
+ dpmac15: dpmac@f {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xf>;
+ };
+
+ dpmac16: dpmac@10 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x10>;
+ };
+ };
+ };
+
+ smmu: iommu@5000000 {
+ compatible = "arm,mmu-500";
+ reg = <0 0x5000000 0 0x800000>;
+ #global-interrupts = <12>;
+ interrupts = <0 13 4>, /* global secure fault */
+ <0 14 4>, /* combined secure interrupt */
+ <0 15 4>, /* global non-secure fault */
+ <0 16 4>, /* combined non-secure interrupt */
+ /* performance counter interrupts 0-7 */
+ <0 211 4>, <0 212 4>,
+ <0 213 4>, <0 214 4>,
+ <0 215 4>, <0 216 4>,
+ <0 217 4>, <0 218 4>,
+ /* per context interrupt, 64 interrupts */
+ <0 146 4>, <0 147 4>,
+ <0 148 4>, <0 149 4>,
+ <0 150 4>, <0 151 4>,
+ <0 152 4>, <0 153 4>,
+ <0 154 4>, <0 155 4>,
+ <0 156 4>, <0 157 4>,
+ <0 158 4>, <0 159 4>,
+ <0 160 4>, <0 161 4>,
+ <0 162 4>, <0 163 4>,
+ <0 164 4>, <0 165 4>,
+ <0 166 4>, <0 167 4>,
+ <0 168 4>, <0 169 4>,
+ <0 170 4>, <0 171 4>,
+ <0 172 4>, <0 173 4>,
+ <0 174 4>, <0 175 4>,
+ <0 176 4>, <0 177 4>,
+ <0 178 4>, <0 179 4>,
+ <0 180 4>, <0 181 4>,
+ <0 182 4>, <0 183 4>,
+ <0 184 4>, <0 185 4>,
+ <0 186 4>, <0 187 4>,
+ <0 188 4>, <0 189 4>,
+ <0 190 4>, <0 191 4>,
+ <0 192 4>, <0 193 4>,
+ <0 194 4>, <0 195 4>,
+ <0 196 4>, <0 197 4>,
+ <0 198 4>, <0 199 4>,
+ <0 200 4>, <0 201 4>,
+ <0 202 4>, <0 203 4>,
+ <0 204 4>, <0 205 4>,
+ <0 206 4>, <0 207 4>,
+ <0 208 4>, <0 209 4>;
+ mmu-masters = <&fsl_mc 0x300 0>;
+ };
+
+ dspi: dspi@2100000 {
+ status = "disabled";
+ compatible = "fsl,ls2088a-dspi", "fsl,ls2085a-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2100000 0x0 0x10000>;
+ interrupts = <0 26 0x4>; /* Level high type */
+ clocks = <&clockgen 4 3>;
+ clock-names = "dspi";
+ spi-num-chipselects = <5>;
+ bus-num = <0>;
+ };
+
+ esdhc: esdhc@2140000 {
+ status = "disabled";
+ compatible = "fsl,ls2088a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x2140000 0x0 0x10000>;
+ interrupts = <0 28 0x4>; /* Level high type */
+ clock-frequency = <0>; /* Updated by bootloader */
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ little-endian;
+ bus-width = <4>;
+ };
+
+ gpio0: gpio@2300000 {
+ compatible = "fsl,ls2088a-gpio", "fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <0 36 0x4>; /* Level high type */
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio@2310000 {
+ compatible = "fsl,ls2088a-gpio", "fsl,qoriq-gpio";
+ reg = <0x0 0x2310000 0x0 0x10000>;
+ interrupts = <0 36 0x4>; /* Level high type */
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio@2320000 {
+ compatible = "fsl,ls2088a-gpio", "fsl,qoriq-gpio";
+ reg = <0x0 0x2320000 0x0 0x10000>;
+ interrupts = <0 37 0x4>; /* Level high type */
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio@2330000 {
+ compatible = "fsl,ls2088a-gpio", "fsl,qoriq-gpio";
+ reg = <0x0 0x2330000 0x0 0x10000>;
+ interrupts = <0 37 0x4>; /* Level high type */
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ i2c0: i2c@2000000 {
+ status = "disabled";
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2000000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; /* Level high type */
+ clock-names = "i2c";
+ clocks = <&clockgen 4 3>;
+ };
+
+ i2c1: i2c@2010000 {
+ status = "disabled";
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2010000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; /* Level high type */
+ clock-names = "i2c";
+ clocks = <&clockgen 4 3>;
+ };
+
+ i2c2: i2c@2020000 {
+ status = "disabled";
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2020000 0x0 0x10000>;
+ interrupts = <0 35 0x4>; /* Level high type */
+ clock-names = "i2c";
+ clocks = <&clockgen 4 3>;
+ };
+
+ i2c3: i2c@2030000 {
+ status = "disabled";
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2030000 0x0 0x10000>;
+ interrupts = <0 35 0x4>; /* Level high type */
+ clock-names = "i2c";
+ clocks = <&clockgen 4 3>;
+ };
+
+ ifc: ifc@2240000 {
+ compatible = "fsl,ifc", "simple-bus";
+ reg = <0x0 0x2240000 0x0 0x20000>;
+ interrupts = <0 21 0x4>; /* Level high type */
+ little-endian;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0x5 0x80000000 0x08000000
+ 2 0 0x5 0x30000000 0x00010000
+ 3 0 0x5 0x20000000 0x00010000>;
+ };
+
+ qspi: quadspi@20c0000 {
+ status = "disabled";
+ compatible = "fsl,ls2088a-qspi", "fsl,ls1021a-qspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x20c0000 0x0 0x10000>,
+ <0x0 0x20000000 0x0 0x10000000>;
+ reg-names = "QuadSPI", "QuadSPI-memory";
+ interrupts = <0 25 0x4>; /* Level high type */
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "qspi_en", "qspi";
+ };
+
+ pcie1: pcie@3400000 {
+ compatible = "fsl,ls2088a-pcie", "fsl,ls2080a-pcie",
+ "snps,dw-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x20 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <0 108 0x4>; /* Level high type */
+ interrupt-names = "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 0 109 4>,
+ <0000 0 0 2 &gic 0 0 0 110 4>,
+ <0000 0 0 3 &gic 0 0 0 111 4>,
+ <0000 0 0 4 &gic 0 0 0 112 4>;
+ };
+
+ pcie2: pcie@3500000 {
+ compatible = "fsl,ls2088a-pcie", "fsl,ls2080a-pcie",
+ "snps,dw-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
+ 0x28 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <0 113 0x4>; /* Level high type */
+ interrupt-names = "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x28 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x28 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 0 114 4>,
+ <0000 0 0 2 &gic 0 0 0 115 4>,
+ <0000 0 0 3 &gic 0 0 0 116 4>,
+ <0000 0 0 4 &gic 0 0 0 117 4>;
+ };
+
+ pcie3: pcie@3600000 {
+ compatible = "fsl,ls2088a-pcie", "fsl,ls2080a-pcie",
+ "snps,dw-pcie";
+ reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
+ 0x30 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <0 118 0x4>; /* Level high type */
+ interrupt-names = "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x30 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x30 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 0 119 4>,
+ <0000 0 0 2 &gic 0 0 0 120 4>,
+ <0000 0 0 3 &gic 0 0 0 121 4>,
+ <0000 0 0 4 &gic 0 0 0 122 4>;
+ };
+
+ pcie4: pcie@3700000 {
+ compatible = "fsl,ls2088a-pcie", "fsl,ls2080a-pcie",
+ "snps,dw-pcie";
+ reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
+ 0x38 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <0 123 0x4>; /* Level high type */
+ interrupt-names = "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x38 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x38 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 0 124 4>,
+ <0000 0 0 2 &gic 0 0 0 125 4>,
+ <0000 0 0 3 &gic 0 0 0 126 4>,
+ <0000 0 0 4 &gic 0 0 0 127 4>;
+ };
+
+ sata0: sata@3200000 {
+ status = "disabled";
+ compatible = "fsl,ls2088a-ahci", "fsl,ls2080a-ahci";
+ reg = <0x0 0x3200000 0x0 0x10000>;
+ interrupts = <0 133 0x4>; /* Level high type */
+ clocks = <&clockgen 4 3>;
+ };
+
+ sata1: sata@3210000 {
+ status = "disabled";
+ compatible = "fsl,ls2088a-ahci", "fsl,ls2080a-ahci";
+ reg = <0x0 0x3210000 0x0 0x10000>;
+ interrupts = <0 136 0x4>; /* Level high type */
+ clocks = <&clockgen 4 3>;
+ };
+
+ usb0: usb3@3100000 {
+ status = "disabled";
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 80 0x4>; /* Level high type */
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ };
+
+ usb1: usb3@3110000 {
+ status = "disabled";
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3110000 0x0 0x10000>;
+ interrupts = <0 81 0x4>; /* Level high type */
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ };
+
+ ccn@4000000 {
+ compatible = "arm,ccn-504";
+ reg = <0x0 0x04000000 0x0 0x01000000>;
+ interrupts = <0 12 4>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 1/5] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Linus Walleij @ 2016-11-08 9:34 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Krzysztof Kozlowski, Kukjin Kim, Javier Martinez Canillas,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, Jaehoon Chung,
sw0312.kim, Joonyoung Shim, Inki Dae, Jonghwa Lee, beomho.seo,
jaewon02.kim, human.hwang@
In-Reply-To: <1478155149-28527-2-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch supports the multiple IORESOURCE_MEM resources for one pin-bank.
> In the pre-existing Exynos series, the registers of the gpio bank are included
> in the one memory map. But, some gpio bank need to support the one more memory
> map (IORESOURCE_MEM) because the registers of gpio bank are separated into
> the different memory map.
>
> For example,
> The both ALIVE and IMEM domain have the different memory base address.
> The GFP[1-5] of exynos5433 are composed as following:
> - ALIVE domain : WEINT_* registers
> - IMEM domain : CON/DAT/PUD/DRV/CONPDN/PUDPDN register
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio@vger.kernel.org
> Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied with Krzysztof's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Krzysztof Kozlowski, Kukjin Kim, Javier Martinez Canillas,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, Jaehoon Chung,
sw0312.kim, Joonyoung Shim, Inki Dae, Jonghwa Lee, beomho.seo,
jaewon02.kim, human.hwang@
In-Reply-To: <1478155149-28527-3-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
> to support the multiple memory map because the registers of GPFx are located
> in the different domain.
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Chanwoo Choi, Kukjin Kim, Javier Martinez Canillas, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-samsung-soc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jaehoon Chung, sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ, Joonyoung Shim,
Inki Dae, Jonghwa Lee, beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
jaewon02.kim-Sze3O3UU22JBDgjK7y7TUQ, human.hwang
In-Reply-To: <20161103192002.GB12945@kozik-lap>
On Thu, Nov 3, 2016 at 8:20 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 03, 2016 at 03:39:06PM +0900, Chanwoo Choi wrote:
>> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
>> to support the multiple memory map because the registers of GPFx are located
>> in the different domain.
>>
>> Cc: Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Cc: Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Joonyoung Shim <jy0922.shim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> ---
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>
> I think that, instead of in previous patch, the
> "samsung,exynos5433-pinctrl" compatible should be documented here along
> with information that it requires two addresses for mappings.
True but too small detail to respin the patches about,
and I'm not perfectionist, so patch applied anyways.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-08 9:47 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Thierry Reding, Paul Kocialkowski,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Alexandre Courbot,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161108085420.GG2478-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
On 08/11/16 08:54, Peter De Schrijver wrote:
> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>>
>> On 07/11/16 13:28, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>>>> no OTG-enabled connector.
>>>>
>>>> Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Where is this information coming from? I don't have one of the Nyans
>>> myself, but one of the Tegra132 devices I have, which I think was
>>> derived from one of the Nyans uses one of the external host ports as
>>> forced recovery port, for which it would need OTG.
>>>
>>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
>>> In that case I think one of the ports must be OTG.
>>
>> It is true that the port on the back on the nyan-big can be used with
>> recovery mode. I was thinking that this is not a true OTG port as it is
>> just a 4-pin type A socket and does not have an ID pin. Thinking some
>> more about this the USB spec does include a "Host Negotiation Protocol
>> (HNP)" that allows a host and device to swap roles and so keeping it as
>> OTG seems valid afterall.
>
> I don't think the bootrom implements that though. I expect recovery mode
> to just program the controller in device mode, without performing any
> negotiation.
I am not talking about the bootrom and I would not expect the bootrom to
do that. However, the kernel could.
Cheers
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Adrian Hunter @ 2016-11-08 9:55 UTC (permalink / raw)
To: Scott Branden, Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden
Cc: BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Srinath Mannam
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 01/11/16 18:37, Scott Branden wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
This is unchanged from V1 which I acked, so:
Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Linus Walleij @ 2016-11-08 10:15 UTC (permalink / raw)
To: Laxman Dewangan
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Stephen Warren, Rob Herring, Mark Rutland, Jon Hunter,
Masahiro Yamada,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <58201401.8050805-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Mon, Nov 7, 2016 at 6:41 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On Saturday 05 November 2016 03:54 AM, Linus Walleij wrote:
>> On Wed, Nov 2, 2016 at 10:09 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
(....)
>>> On Tegra124, the IO power rail source is auto detected by SoC and hence
>>> it is only require to configure in low power mode if IO pads are not
>>> used.
>>>
>>> On T210 onwards, the auto-detection is removed from SoC and hence SW
>>> must configure the PMC register explicitly to set proper voltage in
>>> IO pads based on IO rail power source voltage.
(...)
>>> +static const struct pinconf_generic_params tegra_io_pads_cfg_params[] =
>>> {
>>> + {
>>> + .property = "nvidia,power-source-voltage",
>>> + .param = TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE,
>>> + },
>>> +};
>>
>> Why can you not use the standard power-source binding
>> from Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>> instead of inventing this nvidia,* variant?
>
>
> Per binding doc,
> power-source - select between different power supplies
>
> So actually it selects the different source of power supply.
> In my case, I will have same supply but voltage of that supply get changed.
> So here property is for the power-supply-voltage.
I doubt that seriously. Are you sure? Then the commit message is
misleading because it is talking about different power rails.
The usual design of such IP is that there is a switch that select
a voltage from several available rails and this is what the commit
message seems to be saying, and that is what the binding is for.
If you could actually change the voltage it would change for all
other pins using the same voltage source as well, would it not?
Unless there is one voltage regulator per pin, which seems like
a very expensive and chip surface consuming solution. (Albeit
theoretically possible.)
If you can *actually* change the volatage, it needs to be modeled
as a (fixed voltage?) regulator, not as a custom property for the pin
control attributes. I guess you definiately need the regulator framework
to accumulate and infer the different consumer requirements anyway
in that case.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-08 10:20 UTC (permalink / raw)
To: Linus Walleij
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Stephen Warren, Rob Herring, Mark Rutland, Jon Hunter,
Masahiro Yamada,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdZo+527t4O9gX0U2VOaAYj7fnt7X0wynByBdYN5=2mDsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 08 November 2016 03:45 PM, Linus Walleij wrote:
> On Mon, Nov 7, 2016 at 6:41 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On Saturday 05 November 2016 03:54 AM, Linus Walleij wrote:
>>> On Wed, Nov 2, 2016 at 10:09 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> (....)
>>>> On Tegra124, the IO power rail source is auto detected by SoC and hence
>>>> it is only require to configure in low power mode if IO pads are not
>>>> used.
>>>>
>>>> On T210 onwards, the auto-detection is removed from SoC and hence SW
>>>> must configure the PMC register explicitly to set proper voltage in
>>>> IO pads based on IO rail power source voltage.
> (...)
>>>> +static const struct pinconf_generic_params tegra_io_pads_cfg_params[] =
>>>> {
>>>> + {
>>>> + .property = "nvidia,power-source-voltage",
>>>> + .param = TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE,
>>>> + },
>>>> +};
>>> Why can you not use the standard power-source binding
>>> from Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>>> instead of inventing this nvidia,* variant?
>>
>> Per binding doc,
>> power-source - select between different power supplies
>>
>> So actually it selects the different source of power supply.
>> In my case, I will have same supply but voltage of that supply get changed.
>> So here property is for the power-supply-voltage.
> I doubt that seriously. Are you sure? Then the commit message is
> misleading because it is talking about different power rails.
The set of pins belongs to the IO pad group and this pad group has power
supply from external PMIC. The IO pads support multi-level voltage and
the level need to be configured in the PMIC rail via regulator calls and
the IO pads configuration register for that level.
> The usual design of such IP is that there is a switch that select
> a voltage from several available rails and this is what the commit
> message seems to be saying, and that is what the binding is for.
There is no switch to select the power source inside IP. We have only
one source for supply these pins (IO pads) and the source voltage can be
change here.
>
> If you could actually change the voltage it would change for all
> other pins using the same voltage source as well, would it not?
There is grouping of pins based on interface and yes, voltage level gets
changed for those group of pins. Like form SDMMC interface all data nd
clock lines, for i2c SCL and SDA lines etc.
The HW IP design is like that from single IO voltage source, all pins
are affected.
>
> Unless there is one voltage regulator per pin, which seems like
> a very expensive and chip surface consuming solution. (Albeit
> theoretically possible.)
>
> If you can *actually* change the volatage, it needs to be modeled
> as a (fixed voltage?) regulator, not as a custom property for the pin
> control attributes. I guess you definiately need the regulator framework
> to accumulate and infer the different consumer requirements anyway
> in that case.
The PMIC voltage output is changed via regulator calls.
Here, we need to have two configruations for given voltage level of
interface:
* One at IO voltage from PMIC via regulator call to change votlage of IO
rail.
* Second, configure the IO pad register to tell the IO voltage level so
that it can configured internally for that level.
^ permalink raw reply
* Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
From: Linus Walleij @ 2016-11-08 10:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jon Hunter, Mark Rutland, Rob Herring, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161107152613.GA2428-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Mon, Nov 7, 2016 at 4:26 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161104 14:50]:
>> +struct of_phandle_args;
>> +
>> #ifdef CONFIG_OF
>>
>> Let's see if it works!
>
> OK so do we know now? It seems there was one more email
> about it but it may have been without it.
I haven't seen anything, I think it JustWorks(TM).
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox