Re: Routable IRQs

2015-12-30 Thread Thomas Gleixner 
Felipe,

On Tue, 29 Dec 2015, Felipe Balbi wrote:
> Anyway, the interesting part is that PRUSS has 64 events (on current
> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
> land. Each of these 64 events can be routed to any of these 10 IRQ
> lines. This might not be very useful on UP (AM335x & AM437x) other than
> the fact that soft-IP drivers running on Linux would need to guarantee
> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
> could have real tangible benefits by means of IRQ affinity, etc.
> 
> So, the question is, what is there in IRQ subsystem today for routable
> IRQ support ?
> 
> If a Diagram helps here's a simple one. Note that I'm not showing
> details on the PRUSS side, but that side can also map events pretty much
> any way it wants.
> 
>  .. ..
>  |  HOST CPU  | |   PRUSS|
>  || ||
>  || ||
>  |   irq0 |<-.--|evt0|
>  ||  |  ||
>  |   irq1 |  |  .---|evt1|
>  ||  |  |   ||
>  |   irq2 |  '--|evt2|
>  || |   ||
>  |   irq3 | |   ||
>  || |   ||
>  |   irq4 | |   | .  |
>  || |   ||
>  |   irq5 | |   | .  |
>  || |   ||
>  |   irq6 | |   | .  |
>  || |   ||
>  |   irq7 |<'   ||
>  || ||
>  |   irq8 | ||
>  || ||
>  |   irq9 |<|evtN|
>  '' ''
> 
> Given this setup, what I want to do, is let soft-IP drivers running on
> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
> still considering how/if we should describe the routing itself or just
> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
> irq0 -> evt10, ...).
> 
> Thoughts ?

I have a few questions:

 - Is there a "mapping" block between PRUSS and the host interrupt controller
   or is this "mapping" block part of PRUSS?

 - We all know how well shared interrupts work. Is there a point of supporting
   64 interrupts when you only have 10 irq lines available?

 - I assume that the PRUSS interrupt mapping is more or less a question of the
   firmware implementation. So you either have a fixed association in the
   firmware which is reflected in the DT description of the IP block or you
   need an interface to tell the PRUSS firmware which event it should map to
   which irq line. Is there actually a value in doing the latter?

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] wlcore/wl12xx: spi: add device tree support

2015-12-30 Thread Rob Herring 
On Wed, Dec 23, 2015 at 10:35:43AM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> ---
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 35 +++

For the binding:

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-12-30 Thread Mark Brown 
On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:

> In my opinion, it would be more elegant to adapt the core regulator
> framework to first enable the GPIO and then call the regulator enable
> ops callback instead of handling the GPIO in the driver.

Why would we want to actively manage both things at runtime?  It's more
work, what do we gain from it?


signature.asc
Description: PGP signature

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

2015-12-30 Thread Paul Kocialkowski 
Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:
> 
> > In my opinion, it would be more elegant to adapt the core regulator
> > framework to first enable the GPIO and then call the regulator enable
> > ops callback instead of handling the GPIO in the driver.
> 
> Why would we want to actively manage both things at runtime?  It's more
> work, what do we gain from it?

Well, I figured that it would be best to disable the EN pin when we're
not using any of the regulators, since that allows the chip to enter
standby mode (and thus consume less power).

Implementing that logic in the driver seems very redundant when we're
one step away from doing it with the core regulator framework.
It is also likely that in the future, other chips will use and need to
handle a global enable pin for the same purpose, while allowing
regulator configuration and enable via registers.

It also doesn't hurt regulators that only use a GPIO for enable.

The diff to do this is very minimal, I already have a patch ready, that
I could send if there is a chance for it to get through.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part

Re: Routable IRQs

2015-12-30 Thread Thomas Gleixner 
Felipe,

On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner  writes:
> >  - Is there a "mapping" block between PRUSS and the host interrupt 
> > controller
> >or is this "mapping" block part of PRUSS?
> 
> The description in TRM is a bit "poor", but from what I can gather, the
> mapping is done on an interrupt controller inside the PRUSS. However,
> Linux is the one who's got the driver for that INTC (well, Linux will be
> the one with the soft ethernet/uart/whatever IP to talk to). All of its
> (INTC's) registers are memory mapped to the ARM side.

Ok. And the INTC registers include the "mapping" configuration, right?
 
> >  - We all know how well shared interrupts work. Is there a point of 
> > supporting
> >64 interrupts when you only have 10 irq lines available?
> 
> I'm looking at these 64 events more like MSI kind of events. It's just

Well, that's fine to look at them this way, but they will end up shared no
matter what.

> that the events themselves can be routed to any of the 10 available HW
> IRQ lines.
> 
> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
> > the
> >firmware implementation. So you either have a fixed association in the
> >firmware which is reflected in the DT description of the IP block or you
> >need an interface to tell the PRUSS firmware which event it should map to
> >which irq line. Is there actually a value in doing the latter?
> 
> right, I'd say the mapping is pretty static. Unless Suman has some extra
> information which I don't. I guess the question was really to see if
> there was an easy way for doing this so we don't have to mess with DTS
> for every other FW and their neighbor.

Well, you will need information about every other firmware simply because you
need to know which events the firmware is actually using and what the purpose
of the particular event is.

Assume you have a simple uart with 3 events (RX, TX, status). So how will the
firmware tell you which event is which? You have a few options:

 1) DT + fixed mapping scheme: 

Describe the PRUSS event number in DT and have a fixed mapping scheme like
the one you mentioned evt0 -> irq0 .

 2) DT + DT mapping scheme

Describe the PRUSS event number in DT and describe the mapping scheme in
DT as well

 3) DT + dynamic mapping scheme

Describe the PRUSS event number in DT and let your interrupt controller
associate the irq number dynamically. That's kind of similar to MSI with
the exception that it needs to support shared interrupts.

 4) Fully dynamic association

Have a query interface to the firmware which tells you which event it uses
for which particular purpose (RX, TX ...) and then establish a dynamic
mapping to one of the interrupts.

Not sure which level of complexity you want :)

Thanks,

tglx



 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Routable IRQs

2015-12-30 Thread Felipe Balbi 

Hi Thomas,

Thomas Gleixner  writes:
> On Tue, 29 Dec 2015, Felipe Balbi wrote:
>> Anyway, the interesting part is that PRUSS has 64 events (on current
>> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
>> land. Each of these 64 events can be routed to any of these 10 IRQ
>> lines. This might not be very useful on UP (AM335x & AM437x) other than
>> the fact that soft-IP drivers running on Linux would need to guarantee
>> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
>> could have real tangible benefits by means of IRQ affinity, etc.
>> 
>> So, the question is, what is there in IRQ subsystem today for routable
>> IRQ support ?
>> 
>> If a Diagram helps here's a simple one. Note that I'm not showing
>> details on the PRUSS side, but that side can also map events pretty much
>> any way it wants.
>> 
>>  .. ..
>>  |  HOST CPU  | |   PRUSS|
>>  || ||
>>  || ||
>>  |   irq0 |<-.--|evt0|
>>  ||  |  ||
>>  |   irq1 |  |  .---|evt1|
>>  ||  |  |   ||
>>  |   irq2 |  '--|evt2|
>>  || |   ||
>>  |   irq3 | |   ||
>>  || |   ||
>>  |   irq4 | |   | .  |
>>  || |   ||
>>  |   irq5 | |   | .  |
>>  || |   ||
>>  |   irq6 | |   | .  |
>>  || |   ||
>>  |   irq7 |<'   ||
>>  || ||
>>  |   irq8 | ||
>>  || ||
>>  |   irq9 |<|evtN|
>>  '' ''
>> 
>> Given this setup, what I want to do, is let soft-IP drivers running on
>> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
>> still considering how/if we should describe the routing itself or just
>> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
>> irq0 -> evt10, ...).
>> 
>> Thoughts ?
>
> I have a few questions:
>
>  - Is there a "mapping" block between PRUSS and the host interrupt controller
>or is this "mapping" block part of PRUSS?

The description in TRM is a bit "poor", but from what I can gather, the
mapping is done on an interrupt controller inside the PRUSS. However,
Linux is the one who's got the driver for that INTC (well, Linux will be
the one with the soft ethernet/uart/whatever IP to talk to). All of its
(INTC's) registers are memory mapped to the ARM side.

>  - We all know how well shared interrupts work. Is there a point of supporting
>64 interrupts when you only have 10 irq lines available?

I'm looking at these 64 events more like MSI kind of events. It's just
that the events themselves can be routed to any of the 10 available HW
IRQ lines.

>  - I assume that the PRUSS interrupt mapping is more or less a question of the
>firmware implementation. So you either have a fixed association in the
>firmware which is reflected in the DT description of the IP block or you
>need an interface to tell the PRUSS firmware which event it should map to
>which irq line. Is there actually a value in doing the latter?

right, I'd say the mapping is pretty static. Unless Suman has some extra
information which I don't. I guess the question was really to see if
there was an easy way for doing this so we don't have to mess with DTS
for every other FW and their neighbor.

Chances are (or at least I'm speculating) in most cases we won't use
more than 10 events anyway (Suman ?) so we might not run into any
troubles.

-- 
balbi


signature.asc
Description: PGP signature

Re: Routable IRQs

2015-12-30 Thread Felipe Balbi 

Hi,

Thomas Gleixner  writes:
> Felipe,
>
> On Wed, 30 Dec 2015, Felipe Balbi wrote:
>> Thomas Gleixner  writes:
>> >  - Is there a "mapping" block between PRUSS and the host interrupt 
>> > controller
>> >or is this "mapping" block part of PRUSS?
>> 
>> The description in TRM is a bit "poor", but from what I can gather, the
>> mapping is done on an interrupt controller inside the PRUSS. However,
>> Linux is the one who's got the driver for that INTC (well, Linux will be
>> the one with the soft ethernet/uart/whatever IP to talk to). All of its
>> (INTC's) registers are memory mapped to the ARM side.
>
> Ok. And the INTC registers include the "mapping" configuration, right?

right. A bunch of 32 bit registers each with several 4 bit fields (one
for each of the 64 events) where we write the physical IRQ number.

>> >  - We all know how well shared interrupts work. Is there a point of 
>> > supporting
>> >64 interrupts when you only have 10 irq lines available?
>> 
>> I'm looking at these 64 events more like MSI kind of events. It's just
>
> Well, that's fine to look at them this way, but they will end up
> shared no matter what.

sure :-)

>> that the events themselves can be routed to any of the 10 available HW
>> IRQ lines.
>> 
>> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
>> > the
>> >firmware implementation. So you either have a fixed association in the
>> >firmware which is reflected in the DT description of the IP block or you
>> >need an interface to tell the PRUSS firmware which event it should map 
>> > to
>> >which irq line. Is there actually a value in doing the latter?
>> 
>> right, I'd say the mapping is pretty static. Unless Suman has some extra
>> information which I don't. I guess the question was really to see if
>> there was an easy way for doing this so we don't have to mess with DTS
>> for every other FW and their neighbor.
>
> Well, you will need information about every other firmware simply because you
> need to know which events the firmware is actually using and what the purpose
> of the particular event is.
>
> Assume you have a simple uart with 3 events (RX, TX, status). So how will the
> firmware tell you which event is which? You have a few options:
>
>  1) DT + fixed mapping scheme: 
>
> Describe the PRUSS event number in DT and have a fixed mapping scheme like
> the one you mentioned evt0 -> irq0 .
>
>  2) DT + DT mapping scheme
>
> Describe the PRUSS event number in DT and describe the mapping scheme in
> DT as well
>
>  3) DT + dynamic mapping scheme
>
> Describe the PRUSS event number in DT and let your interrupt controller
> associate the irq number dynamically. That's kind of similar to MSI with
> the exception that it needs to support shared interrupts.
>
>  4) Fully dynamic association
>
> Have a query interface to the firmware which tells you which event it uses
> for which particular purpose (RX, TX ...) and then establish a dynamic
> mapping to one of the interrupts.
>
> Not sure which level of complexity you want :)

I guess only 1, 2 are anything worth considering, most likely. 4 would
just be too much headache :-p

3 might be doable too, though a bit more complex. Suman (who has been
working on this for much longer than I have) might have some extra info
to add, but he's on vacations for now. Hopefully, he'll add to this
thread once he's back.

cheers

-- 
balbi


signature.asc
Description: PGP signature

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

2015-12-30 Thread Paul Kocialkowski 
Hi Milo,

Le mercredi 30 décembre 2015 à 09:22 +0900, Milo Kim a écrit :
> Hi Paul,
> 
> On 29/12/15 20:13, Paul Kocialkowski wrote:
> > Hi Milo,
> >
> > Le mardi 29 décembre 2015 à 09:45 +0900, Milo Kim a écrit :
> >> Hi Paul,
> >>
> >> On 29/12/15 07:49, Paul Kocialkowski wrote:
> >>> Hi Milo, thanks for the review,
> >>>
> >>> Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
>  Hi Paul,
> 
>  On 23/12/15 20:56, Mark Brown wrote:
> > On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >
> >> +  gpio = lp->pdata->enable_gpio;
> >> +  if (!gpio_is_valid(gpio))
> >> +  return 0;
> >> +
> >> +  /* Always set enable GPIO high. */
> >> +  ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, 
> >> "LP872X EN");
> >> +  if (ret) {
> >> +  dev_err(lp->dev, "gpio request err: %d\n", ret);
> >> +  return ret;
> >> +  }
> >
> > This isn't really adding support for the enable GPIO as the changelog
> > suggests, it's requesting but not managing the GPIO.  Since there is
> > core support for manging enable GPIOs this seems especially silly,
> > please tell the core about the GPIO and then it will work at runtime
> > too.
> >
> 
>  With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
>  LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
>  can be controlled by external pin when CONFIG pin is grounded.
> 
>  Please see the description at page 5 of the datasheet.
> 
>   http://www.ti.com/lit/ds/symlink/lp8725.pdf
> >>>
> >>> After reading the datasheets thoroughly, it seems to me that for the
> >>> lp8720, the EN pin is used to enable the regulators output, which is a
> >>> good fit for the core regulator GPIO framework, as there is no reason to
> >>> keep it on when no regulator is in use. The serial interface is already
> >>> available when EN=0 and regulators can be configured in that state. The
> >>> lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
> >>> clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
> >>> EN=0"). On the other hand, it is indeed used as a power-on pin when
> >>> CONFIG=1.
> >>
> >> I think it's different use case. LP8720/5 are designed for system PMU,
> >> so some regulators are enabled by default after the device is on. EN pin
> >> is used for turning on/off the chip. This pin does not control regulator
> >> outputs directly. It's separate functional block in the silicon.
> >
> > Well, I really don't understand why the EN pin would turn on/off the
> > chip. All it does it enable the regulators outputs (by entering IDLE
> > mode), the serial block is already available in STANDBY state.
> >
> > If we want some regulators enabled at boot, the best thing to do seems
> > to be to request the GPIO with the GPIOF_INIT_HIGH flag, as done in e.g.
> > the max8952 regulator driver:
> >
> > if (pdata->reg_data->constraints.boot_on)
> > config.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
> 
> According to MAX8952 datasheet, output regulator is enabled/disabled 
> using EN pin, so ena_gpio is used correctly.
> However, LP8720/5 regulators are enabled/disabled through I2C command. 
> Only few regulators of LP8725 can be on/off by separate external pins. 
> (B2_EN and LDO3_EN)
> Please note that EN pin in LP8720/5 is not the control pin for 
> enabling/disabling regulators.

Oh, I should have mentionned that I also suggest making it possible to
use *both* an enable GPIO and registers to enable a regulator. You are
of course right in saying that the GPIO alone is not enough, and the
core regulator framework will currently only do GPIO or registers to
enable not both.

In my opinion, it would be more elegant to adapt the core regulator
framework to first enable the GPIO and then call the regulator enable
ops callback instead of handling the GPIO in the driver.

However, if that change is not welcome to the core regulator framework,
we'll have to deal with the GPIO in the driver (and probably keep it
enabled at all times there).

Cheers,

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part

[PATCH 3/3] ARM: dts: cm-t335: add audio support

2015-12-30 Thread Uri Mashiach 
The TLV320AIC23B codec is connected to the CPU by McASP controller 1 for
data and I2C0 for control.

Modifications:
- Enable and configure McASP controller 1.
- Add TLV320AIC23B codec pinmux.
- Add TLV320AIC23B codec configurations.
- Use simple-audio-card as CPU to codec glue.

Signed-off-by: Uri Mashiach 
Acked-by: Igor Grinberg 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 69 
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index f232322..080340e 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -56,6 +56,36 @@
brightness-levels = <0 51 53 56 62 75 101 152 255>;
default-brightness-level = <8>;
};
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "cm-t335";
+
+   simple-audio-card,widgets =
+   "Microphone", "Mic Jack",
+   "Line", "Line In",
+   "Headphone", "Headphone Jack";
+
+   simple-audio-card,routing =
+   "Headphone Jack", "LHPOUT",
+   "Headphone Jack", "RHPOUT",
+   "LLINEIN", "Line In",
+   "RLINEIN", "Line In",
+   "MICIN", "Mic Jack";
+
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+
+   sound_master: simple-audio-card,codec {
+   sound-dai = <>;
+   system-clock-frequency = <1200>;
+   };
+   };
 };
 
 _pinmux {
@@ -283,6 +313,20 @@
AM33XX_IOPAD(0x9b4, PIN_OUTPUT | MUX_MODE7)
>;
};
+
+   /* TLV320AIC23B codec */
+   mcasp1_pins: pinmux_mcasp1_pins {
+   pinctrl-single,pins = <
+   /* MII1_CRS.mcasp1_aclkx */
+   AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE4)
+   /* MII1_RX_ER.mcasp1_fsx */
+   AM33XX_IOPAD(0x910, PIN_INPUT_PULLDOWN | MUX_MODE4)
+   /* MII1_COL.mcasp1_axr2 */
+   AM33XX_IOPAD(0x908, PIN_INPUT_PULLDOWN | MUX_MODE4)
+   /* RMII1_REF_CLK.mcasp1_axr3 */
+   AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE4)
+   >;
+   };
 };
 
  {
@@ -317,6 +361,13 @@ status = "okay";
compatible = "emmicro,em3027";
reg = <0x56>;
};
+   /* Audio codec */
+   tlv320aic23: codec@1a {
+   compatible = "ti,tlv320aic23";
+   reg = <0x1a>;
+   #sound-dai-cells= <0>;
+   status = "okay";
+   };
 };
 
  {
@@ -495,3 +546,21 @@ status = "okay";
};
 };
 
+/* CPU audio */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   /* 16 serializers */
+   num-serializer = <16>;
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0
+   >;
+   tx-num-evt = <1>;
+   rx-num-evt = <1>;
+
+   #sound-dai-cells= <0>;
+   status = "okay";
+};
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: dts: cm-t335: Add support for CAN bus

2015-12-30 Thread Uri Mashiach 
Add CAN bus pinmux.
Enable D_CAN bus controllers 0 and 1

The pinmux of uart1 node contradicts the pinmux of dcan0 and dcan1 nodes.
U-Boot should delete the uart1 or dcan0/1 nodes.

Signed-off-by: Uri Mashiach 
Acked-by: Igor Grinberg 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index b700940..f3d7845 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -144,6 +144,24 @@
>;
};
 
+   dcan0_pins: pinmux_dcan0_pins {
+   pinctrl-single,pins = <
+   /* uart1_ctsn.dcan0_tx */
+   AM33XX_IOPAD(0x978, PIN_OUTPUT | MUX_MODE2)
+   /* uart1_rtsn.dcan0_rx */
+   AM33XX_IOPAD(0x97C, PIN_INPUT | MUX_MODE2)
+   >;
+   };
+
+   dcan1_pins: pinmux_dcan1_pins {
+   pinctrl-single,pins = <
+   /* uart1_rxd.dcan1_tx */
+   AM33XX_IOPAD(0x980, PIN_OUTPUT | MUX_MODE2)
+   /* uart1_txd.dcan1_rx */
+   AM33XX_IOPAD(0x984, PIN_INPUT | MUX_MODE2)
+   >;
+   };
+
ecap0_pins: pinmux_ecap0_pins {
pinctrl-single,pins = <
/* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
@@ -448,3 +466,15 @@ status = "okay";
vwlan-supply = <_fixed>;
};
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+};
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] ARM: dts: cm-t335: add peripherals - part 2

2015-12-30 Thread Uri Mashiach 
Add support for the following peripherals:
- CAN BUS
- Touchscreen
- Audio

Uri Mashiach (3):
  ARM: dts: cm-t335: Add support for CAN bus
  ARM: dts: cm-t335: add touchscreen support
  ARM: dts: cm-t335: add audio support

 arch/arm/boot/dts/am335x-cm-t335.dts | 116 +++
 1 file changed, 116 insertions(+)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: cm-t335: add touchscreen support

2015-12-30 Thread Uri Mashiach 
Touchscreen and analog digital converter configurations.

Signed-off-by: Uri Mashiach 
Acked-by: Igor Grinberg 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index f3d7845..f232322 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -478,3 +478,20 @@ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 };
+
+/* Touschscreen and analog digital converter */
+ {
+   status = "okay";
+   tsc {
+   ti,wires = <4>;
+   ti,x-plate-resistance = <200>;
+   ti,coordinate-readouts = <5>;
+   ti,wire-config = <0x01 0x10 0x23 0x32>;
+   ti,charge-delay = <0x400>;
+   };
+
+   adc {
+   ti,adc-channels = <4 5 6 7>;
+   };
+};
+
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

2015-12-30 Thread Geert Uytterhoeven 
On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring  wrote:
> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>> Some displays have a reset input and/or need a regulator to function
>> properly. Allow to specify them for panel-dpi devices.
>>
>> Signed-off-by: Uwe Kleine-König 
>> ---
>>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
>> b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> index 216c894d4f99..b52ac52757df 100644
>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> @@ -7,6 +7,8 @@ Required properties:
>>  Optional properties:
>>  - label: a symbolic name for the panel
>>  - enable-gpios: panel enable gpio
>> +- reset-gpios: GPIO to control the RESET pin
>
> The problem with this in a generic binding is what if the panel has
> ordering requirements like enable gpio has to be inactive when reset
> is deasserted?
>
>> +- vcc-supply: phandle of regulator that will be used to enable power to the 
>> display
>
> What if there are 2 supplies?

So it should be "vcc-supplies". Most properties containing phandles use plural
naming, even if Linux supports a single phandle only (e.g. "power-domains").
You also may want to add an optional "vcc-supply-names" property to
differentiate.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 4.2.0-rc5: am335x: musb warnings

2015-12-30 Thread Yegor Yefremov 
Hi Felipe, hi Ladislav,

On Wed, Oct 14, 2015 at 1:47 AM, Ladislav Michl  wrote:
> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
>> Hi Felipe,
>>
>> On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
>>  wrote:
>> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
>> >  wrote:
>> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
>> >>> HI,
>> >>>
>> >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>>  I performed a stress test with several FT4232H chips connected to a
>> >>>
>> >>> how many ?
>> >>
>> >> # lsusb -t
>> >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
>> >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
>> >>
>> >> 3 chips a 4-ports are attached.
>> >
>> > Warnings appear on another device (without internal hub) with only one
>> > FT4232H too:
>> >
>> > # lsusb -t
>> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
>> > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
>> > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
>> > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
>> >
>>  hub, that is attached to one of the musb ports. So far the test was
>>  successful for several hours. But I've seen following warnings:
>> 
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
>> 
>>  Is this expected behavior?
>> >>>
>> >>> no, that shouldn't happen, but it does and, apparently, in more than one
>> >>> implementation. Wondering if you're running into endpoint limitation due
>> >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
>
> To add more:
> kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged:
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 
> 480M
> |__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 
> 480M
> |__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 
> 480M
> |__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 
> 480M
> |__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 
> 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
>
>  musb_ep_program 931: broken !rx_reinit, ep2 csr a203
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep5 csr a203
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>
> and in both PIO and DMA mode write to device ends this way:
>  [ cut here ]
>  WARNING: CPU: 0 PID: 146 at drivers/usb/musb/musb_host.c:128 
> musb_h_tx_flush_fifo+0x84/0xb8()
>  Could not flush host TX2 fifo: csr: 2003
>  Modules linked in: option usb_wwan usbserial snd_soc_omap_twl4030 cpufreq_dt 
> snd_soc_omap_mcbsp snd_soc_omap snd_soc_twl4030 snd_pcm_dmaengine omap_aes 
> snd_soc_core omap_sham omap_mailbox s
>  CPU: 0 PID: 146 Comm: ModemManager Not tainted 4.2.0 #3
>  Hardware name: Generic OMAP36xx (Flattened Device Tree)
>  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>  [] (show_stack) from [] (warn_slowpath_common+0x84/0xac)
>  [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x2c/0x3c)
>  [] (warn_slowpath_fmt) from [] 
> (musb_h_tx_flush_fifo+0x84/0xb8)
>  []

[PATCH 5/6] ARM: dts: am57xx: cl-som-am57x: fix CPSW EMAC pinmux

2015-12-30 Thread Dmitry Lifshitz 
Fix CPSW EMAC pinmux

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index cb9a518..9e0153a 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -167,7 +167,7 @@
DRA7XX_CORE_IOPAD(0x35b8, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d20.rgmii1_rd3 */
DRA7XX_CORE_IOPAD(0x35bc, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d21.rgmii1_rd2 */
DRA7XX_CORE_IOPAD(0x35c0, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d22.rgmii1_rd1 */
-   DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT_PULLUP | MUX_MODE3) 
/* vin2a_d23.rgmii1_rd0 */
+   DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d23.rgmii1_rd0 */
>;
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] ARM: dts: am57xx: cl-som-am57x: set of non critical DT fixes

2015-12-30 Thread Dmitry Lifshitz 
This pacth set apply a set of non critical DT fixes for CompuLab CL-SOM-AM57x 
SoM

* Improve Eth functionality
* Pinmux fix for several devices
* Improve SPI flash access
* Set USB2 in HOST mode to enable connection of keyboard/mouse on eval board

Dmitry Lifshitz (6):
  ARM: dts: am57xx: sbc-am57x: fix SB-SOM EEPROM I2C address
  ARM: dts: am57xx: cl-som-am57x: set HOST mode for USB2
  ARM: dts: am57xx: cl-som-am57x: update SPI Flash frequency
  ARM: dts: am57xx: sbc-am57x: fix UART3 pinmux
  ARM: dts: am57xx: cl-som-am57x: fix CPSW EMAC pinmux
  ARM: dts: am57xx: sbc-am57x: correct Eth PHY settings

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 12 ++--
 arch/arm/boot/dts/am57xx-sbc-am57x.dts|  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] ARM: dts: am57xx: cl-som-am57x: set HOST mode for USB2

2015-12-30 Thread Dmitry Lifshitz 
Setup USB2 to act in "HOST" mode by default.

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index c538826..513ec62 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -588,7 +588,7 @@
 };
 
  {
-   dr_mode = "peripheral";
+   dr_mode = "host";
 };
 
  {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] ARM: dts: am57xx: sbc-am57x: fix UART3 pinmux

2015-12-30 Thread Dmitry Lifshitz 
Fix UART3 pinmux.

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 0f1d425..988e996 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -25,8 +25,8 @@
 _pmx_core {
uart3_pins_default: uart3_pins_default {
pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
/* uart2_ctsn.uart3_rxd */
-   DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
/* uart2_rtsn.uart3_txd */
+   DRA7XX_CORE_IOPAD(0x3648, PIN_INPUT_SLEW | MUX_MODE0)   
/* uart3_rxd */
+   DRA7XX_CORE_IOPAD(0x364c, PIN_INPUT_SLEW | MUX_MODE0)   
/* uart3_txd */
>;
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] ARM: dts: am57xx: sbc-am57x: correct Eth PHY settings

2015-12-30 Thread Dmitry Lifshitz 
Update Eth PHY settings to make it possible to run both phys at 1Gbps.

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 9e0153a..8d93882 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -559,13 +559,13 @@
 
 _emac0 {
phy_id = <_mdio>, <0>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-txid";
dual_emac_res_vlan = <0>;
 };
 
 _emac1 {
phy_id = <_mdio>, <1>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-txid";
dual_emac_res_vlan = <1>;
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] ARM: dts: am57xx: sbc-am57x: fix SB-SOM EEPROM I2C address

2015-12-30 Thread Dmitry Lifshitz 
Fix SB-SOM EEPROM I2C address

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 77bb8e1..0f1d425 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -108,9 +108,9 @@
pinctrl-0 = <_pins_default>;
clock-frequency = <40>;
 
-   eeprom_base: atmel@50 {
+   eeprom_base: atmel@54 {
compatible = "atmel,24c08";
-   reg = <0x50>;
+   reg = <0x54>;
pagesize = <16>;
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] ARM: dts: am57xx: cl-som-am57x: update SPI Flash frequency

2015-12-30 Thread Dmitry Lifshitz 
On-board SPI flash cat act at 48Mhz SPI bus frequency.
Update the DT frequency property.

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 513ec62..cb9a518 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -492,14 +492,14 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 
-   spi-max-frequency = <2000>;
+   spi-max-frequency = <4800>;
 
spi_flash: spi_flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,m25p80", "jedec,spi-nor";
reg = <0>;  /* CS0 */
-   spi-max-frequency = <2000>;
+   spi-max-frequency = <4800>;
 
partition@0 {
label = "uboot";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] mtd: nand: Fix support for NAND DMA prefetch

2015-12-30 Thread Franklin S Cooper Jr. 


On 12/18/2015 12:04 PM, Brian Norris wrote:
> On Thu, Oct 15, 2015 at 12:37:23PM -0500, Franklin S Cooper Jr wrote:
>> NAND DMA prefetch has been broken for awhile and seems to have only
>> worked for SDMA based devices
>>
>> This patchset fixes DMA prefetch to work on both EDMA and SDMA devices
>>
>> Test on:
>> am335x gp evm
>> am437x gp evm
>> am37x gp evm
>>
>> This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset
>> https://github.com/rogerq/linux.git
>> branch: for-v4.4/gpmc-v4
> In what way does this depend on the other series? Can any of this be
> taken without it? If not, then perhaps it'd be good if Roger can roll
> this into his series? Just throwing out ideas. If you want to wait on
> Roger's series, that's fine.
>
> FWIW, the MTD stuff all looks OK to me:
>
> Acked-by: Brian Norris 

Patches 2 and 3 doesn't have any dependencies on Roger's
patchset so they should be fine to pull in.

I'll leave it up to Roger if he would like to roll my
patches into his patchset or I can submit the other 3
patches again once he sends out his new patchset.

>> Franklin S Cooper Jr (5):
>>   mtd: nand: omap2: Support parsing dma channel information from DT
>>   mtd: nand: omap2: Start dma request before enabling prefetch
>>   mtd: nand: omap2: Fix high memory dma prefetch transfer
>>   ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
>>   ARM: OMAP2+: Update GPMC and NAND DT binding documentation
>>
>>  .../bindings/memory-controllers/omap-gpmc.txt  |  7 +-
>>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
>>  arch/arm/boot/dts/am33xx.dtsi  |  2 ++
>>  arch/arm/boot/dts/am4372.dtsi  |  2 ++
>>  arch/arm/boot/dts/dm816x.dtsi  |  2 ++
>>  arch/arm/boot/dts/omap3.dtsi   |  2 ++
>>  arch/arm/boot/dts/omap4.dtsi   |  2 ++
>>  arch/arm/boot/dts/omap5.dtsi   |  2 ++
>>  drivers/mtd/nand/omap2.c   | 27 
>> +-
>>  9 files changed, 31 insertions(+), 17 deletions(-)
>>
>> -- 
>> 2.6.1
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 4.2.0-rc5: am335x: musb warnings

2015-12-30 Thread Felipe Balbi 

Hi,

Yegor Yefremov  writes:
> Hi Felipe, hi Ladislav,
>
> On Wed, Oct 14, 2015 at 1:47 AM, Ladislav Michl  wrote:
>> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
>>> Hi Felipe,
>>>
>>> On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
>>>  wrote:
>>> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
>>> >  wrote:
>>> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
>>> >>> HI,
>>> >>>
>>> >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>>>  I performed a stress test with several FT4232H chips connected to a
>>> >>>
>>> >>> how many ?
>>> >>
>>> >> # lsusb -t
>>> >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>> >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
>>> >>
>>> >> 3 chips a 4-ports are attached.
>>> >
>>> > Warnings appear on another device (without internal hub) with only one
>>> > FT4232H too:
>>> >
>>> > # lsusb -t
>>> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
>>> >
>>>  hub, that is attached to one of the musb ports. So far the test was
>>>  successful for several hours. But I've seen following warnings:
>>> 
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>>  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
>>> 
>>>  Is this expected behavior?
>>> >>>
>>> >>> no, that shouldn't happen, but it does and, apparently, in more than one
>>> >>> implementation. Wondering if you're running into endpoint limitation due
>>> >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
>>
>> To add more:
>> kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged:
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
>>
>>  musb_ep_program 931: broken !rx_reinit, ep2 csr a203
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>  musb_ep_program 931: broken !rx_reinit, ep5 csr a203
>>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>>
>> and in both PIO and DMA mode write to device ends this way:
>>  [ cut here ]
>>  WARNING: CPU: 0 PID: 146 at drivers/usb/musb/musb_host.c:128 
>> musb_h_tx_flush_fifo+0x84/0xb8()
>>  Could not flush host TX2 fifo: csr: 2003
>>  Modules linked in: option usb_wwan usbserial snd_soc_omap_twl4030 
>> cpufreq_dt snd_soc_omap_mcbsp snd_soc_omap snd_soc_twl4030 snd_pcm_dmaengine 
>> omap_aes snd_soc_core omap_sham omap_mailbox s
>>  CPU: 0 PID: 146 Comm: ModemManager Not tainted 4.2.0 #3
>>  Hardware name: Generic OMAP36xx (Flattened Device Tree)
>>  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>>  [] (show_stack) from []

[PATCH v4 2/3] wlcore/wl12xx: spi: add device tree support

2015-12-30 Thread Uri Mashiach 
Add DT support for the wl1271 SPI WiFi.

Add documentation file for the wl1271 SPI WiFi.

Signed-off-by: Uri Mashiach 
Acked-by: Rob Herring 
---
v1 -> v2: update interrupt documentation.
  replace interrupts and interrupt-parent with interrupts-extended.
  IRQ parameters retrieved from spi_device instead of DT.
  remove redundant #ifdef CONFIG_OF
v2 -> v3: Add MODULE_DEVICE_TABLE.
  Remove #ifdef CONFIG_OF.
  Make the Kconfig symbol to depend on OF.
  Replace irqd_get_trigger_type() with irq_get_trigger_type().
v3 -> v4: replace interrupts-extended with interrupts and interrupt-parent. 
(revert v2 modification).
  According to Rob Herring and 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt,
  interrupts-extended should only be used when a device has multiple 
interrupt parents.

 .../bindings/net/wireless/ti,wlcore,spi.txt| 36 +
 drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
 drivers/net/wireless/ti/wlcore/spi.c   | 47 --
 3 files changed, 80 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
new file mode 100644
index 000..9180724
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -0,0 +1,36 @@
+* Texas Instruments wl1271 wireless lan controller
+
+The wl1271 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible :  Should be "ti,wl1271"
+- reg : Chip select address of device
+- spi-max-frequency :   Maximum SPI clocking speed of device in Hz
+- ref-clock-frequency : Reference clock frequency
+- interrupt-parent, interrupts :
+Should contain parameters for 1 interrupt line.
+Interrupt parameters: parent, line number, type.
+- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+
+Optional properties:
+- clock-xtal :  boolean, clock is generated from XTAL
+
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+  for optional SPI connection related properties,
+
+Examples:
+
+ {
+   wl1271@1 {
+   compatible = "ti,wl1271";
+
+   reg = <1>;
+   spi-max-frequency = <4800>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   interrupt-parent = <>;
+   interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+   vwlan-supply = <_fixed>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/Kconfig 
b/drivers/net/wireless/ti/wlcore/Kconfig
index 7c09954..5918080 100644
--- a/drivers/net/wireless/ti/wlcore/Kconfig
+++ b/drivers/net/wireless/ti/wlcore/Kconfig
@@ -13,7 +13,7 @@ config WLCORE
 
 config WLCORE_SPI
tristate "TI wlcore SPI support"
-   depends on WLCORE && SPI_MASTER
+   depends on WLCORE && SPI_MASTER && OF
select CRC7
---help---
  This module adds support for the SPI interface of adapters using
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index dec1512..020ac1a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "wlcore.h"
@@ -357,6 +358,39 @@ static struct wl1271_if_operations spi_ops = {
.set_block_size = NULL,
 };
 
+static const struct of_device_id wlcore_spi_of_match_table[] = {
+   { .compatible = "ti,wl1271" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
+
+/**
+ * wlcore_probe_of - DT node parsing.
+ * @spi: SPI slave device parameters.
+ * @res: resource parameters.
+ * @glue: wl12xx SPI bus to slave device glue parameters.
+ * @pdev_data: wlcore device parameters
+ */
+static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue 
*glue,
+  struct wlcore_platdev_data *pdev_data)
+{
+   struct device_node *dt_node = spi->dev.of_node;
+   int ret;
+
+   if (of_find_property(dt_node, "clock-xtal", NULL))
+   pdev_data->ref_clock_xtal = true;
+
+   ret = of_property_read_u32(dt_node, "ref-clock-frequency",
+  _data->ref_clock_freq);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(glue->dev,
+   "can't get reference clock frequency (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int wl1271_probe(struct spi_device *spi)
 {
struct wl12xx_spi_glue *glue;
@@ -366,8 +400,6 @@ static int wl1271_probe(struct spi_device *spi)

[PATCH v4 0/3] wlcore/wl12xx: spi: add wifi support to cm-t335

2015-12-30 Thread Uri Mashiach 
Add DT support for WLS1271 SPI driver.
Add power operation function to the WLS1271 SPI driver.

Uri Mashiach (3):
  wlcore/wl12xx: spi: add power operation function
  wlcore/wl12xx: spi: add device tree support
  wlcore/wl12xx: spi: add wifi support to cm-t335

 .../bindings/net/wireless/ti,wlcore,spi.txt| 36 +
 arch/arm/boot/dts/am335x-cm-t335.dts   | 55 ++
 drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
 drivers/net/wireless/ti/wlcore/spi.c   | 86 +-
 4 files changed, 174 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335

2015-12-30 Thread Uri Mashiach 
Device tree modifications:
- Pinmux for SPI0 and WiFi GPIOs.
- SPI0 node with wlcore as a child node.

Cc: Tony Lindgren 
Signed-off-by: Uri Mashiach 
---
v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
v2 -> v3: Move the pinctrl-0 = <_pins> to the wlcore node.
v3 -> v4: replace interrupts-extended with interrupts and interrupt-parent. 
(revert v2 modification).
  According to Rob Herring and 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt,
  interrupts-extended should only be used when a device has multiple 
interrupt parents.

 arch/arm/boot/dts/am335x-cm-t335.dts | 55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 42e9b66..65f1099 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -11,6 +11,7 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include 
 
 / {
model = "CompuLab CM-T335";
@@ -40,6 +41,15 @@
regulator-max-microvolt = <330>;
};
 
+   /* Regulator for WiFi */
+   vwlan_fixed: fixedregulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vwlan_fixed";
+   gpio = < 20 GPIO_ACTIVE_HIGH>; /* gpio0_20 */
+   enable-active-high;
+   regulator-boot-off;
+   };
+
backlight {
compatible = "pwm-backlight";
pwms = < 0 5 0>;
@@ -223,6 +233,21 @@
>;
};
 
+   spi0_pins: pinmux_spi0_pins {
+   pinctrl-single,pins = <
+   /* spi0_sclk.spi0_sclk */
+   AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE0)
+   /* spi0_d0.spi0_d0 */
+   AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLUP | MUX_MODE0)
+   /* spi0_d1.spi0_d1 */
+   AM33XX_IOPAD(0x958, PIN_INPUT | MUX_MODE0)
+   /* spi0_cs0.spi0_cs0 */
+   AM33XX_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0)
+   /* spi0_cs1.spi0_cs1 */
+   AM33XX_IOPAD(0x960, PIN_OUTPUT | MUX_MODE0)
+   >;
+   };
+
/* wl1271 bluetooth */
bluetooth_pins: pinmux_bluetooth_pins {
pinctrl-single,pins = <
@@ -230,6 +255,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLUP | MUX_MODE7)
>;
};
+
+   /* wl1271 WiFi */
+   wifi_pins: pinmux_wifi_pins {
+   pinctrl-single,pins = <
+   /* EMU1.gpio3_8 - WiFi IRQ */
+   AM33XX_IOPAD(0x9e8, PIN_INPUT_PULLUP | MUX_MODE7)
+   /* XDMA_EVENT_INTR1.gpio0_20 - WiFi enable */
+   AM33XX_IOPAD(0x9b4, PIN_OUTPUT | MUX_MODE7)
+   >;
+   };
 };
 
  {
@@ -394,3 +429,23 @@ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   ti,pindir-d0-out-d1-in = <1>;
+   /* WLS1271 WiFi */
+   wlcore: wlcore@1 {
+   compatible = "ti,wl1271";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   reg = <1>;
+   spi-max-frequency = <4800>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   interrupt-parent = <>;
+   interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+   vwlan-supply = <_fixed>;
+   };
+};
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] wlcore/wl12xx: spi: add power operation function

2015-12-30 Thread Uri Mashiach 
The power function uses a consumer regulator access to update the WiFi
enable GPIO value.

Signed-off-by: Uri Mashiach 
---
v1 -> v2: oops fix was removed to a separate fix.
v2 -> v3: no changes
v3 -> v4: update devm_regulator_get() error handling.

 drivers/net/wireless/ti/wlcore/spi.c | 39 
 1 file changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 44f059f..dec1512 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -81,6 +82,7 @@
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
+   struct regulator *reg; /* Power regulator */
 };
 
 static void wl12xx_spi_reset(struct device *child)
@@ -318,11 +320,40 @@ static int __must_check wl12xx_spi_raw_write(struct 
device *child, int addr,
return 0;
 }
 
+/**
+ * wl12xx_spi_set_power - power on/off the wl12xx unit
+ * @child: wl12xx device handle.
+ * @enable: true/false to power on/off the unit.
+ *
+ * use the WiFi enable regulator to enable/disable the WiFi unit.
+ */
+static int wl12xx_spi_set_power(struct device *child, bool enable)
+{
+   int ret = 0;
+   struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
+
+   WARN_ON(!glue->reg);
+
+   /* Update regulator state */
+   if (enable) {
+   ret = regulator_enable(glue->reg);
+   if (ret)
+   dev_err(child, "Power enable failure\n");
+   } else {
+   ret =  regulator_disable(glue->reg);
+   if (ret)
+   dev_err(child, "Power disable failure\n");
+   }
+
+   return ret;
+}
+
 static struct wl1271_if_operations spi_ops = {
.read   = wl12xx_spi_raw_read,
.write  = wl12xx_spi_raw_write,
.reset  = wl12xx_spi_reset,
.init   = wl12xx_spi_init,
+   .power  = wl12xx_spi_set_power,
.set_block_size = NULL,
 };
 
@@ -353,6 +384,14 @@ static int wl1271_probe(struct spi_device *spi)
 * comes from the board-peripherals file */
spi->bits_per_word = 32;
 
+   glue->reg = devm_regulator_get(>dev, "vwlan");
+   if (PTR_ERR(glue->reg) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   if (IS_ERR(glue->reg)) {
+   dev_err(glue->dev, "can't get regulator\n");
+   return PTR_ERR(glue->reg);
+   }
+
ret = spi_setup(spi);
if (ret < 0) {
dev_err(glue->dev, "spi_setup failed\n");
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

2015-12-30 Thread Rob Herring 
On Wed, Dec 30, 2015 at 4:29 AM, Geert Uytterhoeven
 wrote:
> On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring  wrote:
>> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>>> Some displays have a reset input and/or need a regulator to function
>>> properly. Allow to specify them for panel-dpi devices.
>>>
>>> Signed-off-by: Uwe Kleine-König 
>>> ---
>>>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
>>> b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> index 216c894d4f99..b52ac52757df 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> @@ -7,6 +7,8 @@ Required properties:
>>>  Optional properties:
>>>  - label: a symbolic name for the panel
>>>  - enable-gpios: panel enable gpio
>>> +- reset-gpios: GPIO to control the RESET pin
>>
>> The problem with this in a generic binding is what if the panel has
>> ordering requirements like enable gpio has to be inactive when reset
>> is deasserted?
>>
>>> +- vcc-supply: phandle of regulator that will be used to enable power to 
>>> the display
>>
>> What if there are 2 supplies?
>
> So it should be "vcc-supplies". Most properties containing phandles use plural
> naming, even if Linux supports a single phandle only (e.g. "power-domains").
> You also may want to add an optional "vcc-supply-names" property to
> differentiate.

True, but the regulator binding is an exception and we don't do that
with it. The prefix is the name and other supplies are not going to be
called Vcc.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html