Re: [PATCH 2/7] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

[Maxime Coquelin]

2015-10-15 13:14 GMT+02:00 Daniel Thompson :
> On 14/10/15 21:07, Maxime Coquelin wrote:
>>
>> Signed-off-by: Maxime Coquelin 
>> ---
>>   include/dt-bindings/pinctrl/pinctrl-stm32.h |   12 +
>>   include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241
>> +++
>>   2 files changed, 1253 insertions(+)
>>   create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
>>   create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>>
>> diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> b/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> new file mode 100644
>> index 000..a2e7222
>> --- /dev/null
>> +++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
>> @@ -0,0 +1,12 @@
>> +#ifndef _DT_BINDINGS_PINCTRL_STM32_H
>> +#define _DT_BINDINGS_PINCTRL_STM32_H
>> +
>> +#define STM32_PIN_NO(x) ((x) << 8)
>> +#define STM32_GET_PIN_NO(x) ((x) >> 8)
>> +#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
>> +
>> +#define STM32_PIN_GPIO 0
>> +#define STM32_PIN_AF(x)((x) + 1)
>> +#define STM32_PIN_ANALOG   (STM32_PIN_AF(15) + 1)
>> +
>> +#endif /* _DT_BINDINGS_PINCTRL_STM32_H */
>> diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> new file mode 100644
>> index 000..979e4eb
>> --- /dev/null
>> +++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
>> @@ -0,0 +1,1241 @@
>> +#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
>> +#define _DT_BINDINGS_STM32F429_PINFUNC_H
>> +
>> +#include 
>> +
>> +#define STM32F429_PA0_FUNC_GPIO (STM32_PIN_NO(0) | STM32_PIN_GPIO)
>> +#define STM32F429_PA0_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(0) |
>> STM32_PIN_AF(1))
>
>
> For the clock driver I was advised to get rid of this sort of "heroics" and
> expose raw numbers from the datasheet directly to DT bindings users.
>
> Should the same logic apply to this *huge* collection of macros?

I'm open to change, I just took example on the Mediatek implementation.
Advantage is that checkpatch will be more silent, drawback is that it
will be a little harder to understand how these values are generated.
If we decide to change to raw values, then the DT Bindings
documentation will need to be more verbose on the way these values are
generated.

Note that it will not be painful, as I can generate them from a script.

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

Re: [PATCH 3/4] mmc: mediatek: Add tune support

[Chaotian Jing]

On Thu, 2015-10-15 at 11:17 +0200, Ulf Hansson wrote:
> [...]
> 
> >> >
> >> > struct clk *src_clk;/* msdc source clock */
> >> > +   struct clk *src_clk_parent; /* src_clk's parent */
> >> > +   struct clk *hs400_src;  /* 400Mhz source clock */
> >>
> >> Hmm, so you need to control the upper level clocks. Can you elaborate
> >> on why this is needed?
> >>
> > hs400 is DDR200, in our host design, if the mode is DDR(HS400), if want
> > to get 200Mhz mmc bus clock frequency, the minimum source clock is
> > double of the mmc bus clock, So, we need it for HS400 mode with 200Mhz
> > bus clock.
> 
> Thanks for clarifying.
> 
> [...]
> 
>  > flags = readl(host->base + MSDC_INTEN);
> >> > sdr_clr_bits(host->base + MSDC_INTEN, flags);
> >> > -   if (ddr) { /* may need to modify later */
> >> > -   mode = 0x2; /* ddr mode and use divisor */
> >> > +   sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
> >> > +   if (timing == MMC_TIMING_UHS_DDR50 ||
> >> > +   timing == MMC_TIMING_MMC_DDR52 ||
> >>
> >> So, no support for HS200?
> >>
> > HS200 is the same with other SDR modes, so it will be handled at else..
> 
> Okay, nice!
> 
> So, your the driver currently supports HS200, but without need for tuning!?
> 

It support and need tuning for HS200, but do not support tuning for
HS400, that's why we fixed the hs400_ds_delay by project.

> [...]
> 
> >> > +static struct msdc_delay_phase get_best_delay(u32 delay)
> >> > +{
> >> > +   int start = 0, len = 0;
> >> > +   int start_final = 0, len_final = 0;
> >> > +   u8 final_phase = 0xff;
> >> > +   struct msdc_delay_phase delay_phase;
> >> > +
> >> > +   if (delay == 0) {
> >> > +   pr_err("phase error: [map:%x]\n", delay);
> >>
> >> Please use dev_err|warn|dbg|info instead.
> >>
> > As you know, this function is just only parse the argument "u32 delay",
> > it do not bind with any device.
> 
> You may just add a msdc_host * as a parameter to the function, that
> would solve this.
> 

Ok, will do it.

> [...]
> 
> >> > +static int msdc_send_tuning(struct mmc_host *host, u32 opcode, int 
> >> > *cmd_error)
> >>
> >> I think you can remove this function and use mmc_send_tuning() instead.
> > Hmm, I also noticed that there was a mmc_send_tuning, but, I need to get
> > the cmd_error when tune cmd response, in this case, do not care the data
> > error.
> 
> Well, if you need to extend the mmc_send_tuning() API to suite your
> needs, let's do that instead of duplicating code.
> 

OK, will extend the mmc_send_tuning, but it need change other vendor's
MMC driver, because it already use the mmc_send_tuning()

> >>
> >> > +{
> >> > +   struct mmc_request mrq = {NULL};
> >> > +   struct mmc_command cmd = {0};
> >> > +   struct mmc_data data = {0};
> >> > +   struct scatterlist sg;
> >> > +   struct mmc_ios *ios = >ios;
> >> > +   int size, err = 0;
> >> > +   u8 *data_buf;
> >> > +
> >> > +   if (ios->bus_width == MMC_BUS_WIDTH_8)
> >> > +   size = 128;
> >> > +   else if (ios->bus_width == MMC_BUS_WIDTH_4)
> >> > +   size = 64;
> >> > +   else
> >> > +   return -EINVAL;
> >> > +
> >> > +   data_buf = kzalloc(size, GFP_KERNEL);
> >> > +   if (!data_buf)
> >> > +   return -ENOMEM;
> >> > +
> >> > +   mrq.cmd = 
> >> > +   mrq.data = 
> >> > +
> >> > +   cmd.opcode = opcode;
> >> > +   cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> >> > +
> >> > +   data.blksz = size;
> >> > +   data.blocks = 1;
> >> > +   data.flags = MMC_DATA_READ;
> >> > +
> >> > +   /*
> >> > +* According to the tuning specs, Tuning process
> >> > +* is normally shorter 40 executions of CMD19,
> >> > +* and timeout value should be shorter than 150 ms
> >> > +*/
> >> > +   data.timeout_ns = 150 * NSEC_PER_MSEC;
> >> > +
> >> > +   data.sg = 
> >> > +   data.sg_len = 1;
> >> > +   sg_init_one(, data_buf, size);
> >> > +
> >> > +   mmc_wait_for_req(host, );
> >> > +
> >> > +   if (cmd_error)
> >> > +   *cmd_error = cmd.error;
> >> > +
> >> > +   if (cmd.error) {
> >> > +   err = cmd.error;
> >> > +   goto out;
> >> > +   }
> >> > +
> >> > +   if (data.error) {
> >> > +   err = data.error;
> >> > +   goto out;
> >> > +   }
> >> > +
> >> > +out:
> >> > +   kfree(data_buf);
> >> > +   return err;
> >> > +}
> >> > +
> 
> [...]
> 
> >> > +   host->src_clk_parent = clk_get_parent(host->src_clk);
> >>
> >> Don't you need to check the return value here?
> >>
> > will check it.
> >> > +   host->hs400_src = devm_clk_get(>dev, "400mhz");
> >>
> >> That's a really weird conid for a clock. If it's not too late to
> >> change, please do that!
> >>
> >> > +   if (IS_ERR(host->hs400_src)) {
> >> > +   dev_dbg(>dev, "Cannot find 400mhz at 

Re: [PATCH 0/4] Enable Ethernet on StiH407 family boards

[Maxime Coquelin]

On 10/01/2015 05:56 PM, Maxime Coquelin wrote:

This series enables Ethernet support on STiH407 family reference design
boards.

These boards use the RTL8367 Switch as PHY.
As it is previously configured by the bootloader, we declare it as a fixed
link.

Maxime Coquelin (4):
   ARM: dts: Fix RGMII pinctrl timings
   ARM: dts: Add Ethernet node to STiH407 family
   ARM: dts: Enable Ethernet on STi's B2120 boards
   ARM: dts: Enable Ethernet on STi's B2199 board

  arch/arm/boot/dts/stih407-b2120.dts|  1 +
  arch/arm/boot/dts/stih407-family.dtsi  | 27 +++
  arch/arm/boot/dts/stih407-pinctrl.dtsi |  4 ++--
  arch/arm/boot/dts/stih410-b2120.dts|  1 +
  arch/arm/boot/dts/stih418-b2199.dts|  8 
  arch/arm/boot/dts/stihxxx-b2120.dtsi   |  6 ++
  6 files changed, 45 insertions(+), 2 deletions(-)


Series applied.

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

[PATCH v3 0/4] Add support for STM32 DMA

[M'boumba Cedric Madianga]

This patchset adds support for the STM32 DMA controller.
This controller provides 8 channels dedicated to managing memory access
request from one or more peripherals.
Each stream can have up to 8 requests in total.

Changes since v2:
- remove interrupt configuration management from DT
- remove FIFO configuration management from DT except threshold as it is very
  hard to handle it in the driver due to many possible combinations according
  to burst and bus width
- update DMA client message in DT documentation file
- specify the order to be used to set per-channel DMA interrupts in the DT
- remove unused enumerations for channel and request ids
- keep as soon as possible 80 lines char for more readability
- replace unsigned int by u32
- return error if burst is not supported in stm32_dma_get_burst()
- return error if bus_width is not supported in stm32_dma_get_width()
- add FIFO configuration management inside the driver except for threshold
- add interrupt configuration management inside the driver
- rework stm32_dma_chan_irq() to handle error interrupt in one way
- rework stm32_dma_set_xfer_param() to be easier to read
- update stm32_dma_tx_status() to always return status from dma_cookie_status()
- disable clk if we don't manage to stop the DMA channel during channel
  resources allocation
- set driver as built-in as DMA will be required by other built-in driver

Changes since v1:
 - remove dmamux boolean as it is not needed
 - replace dma by DMA in Kconfig
 - add default return value in stm32_dma_get_width()
 - add defalut return value in stm32_dma_get_burst()
 - use lower case for constant hexadecimal values


M'boumba Cedric Madianga (4):
  dt-bindings: Document the STM32 DMA bindings
  dmaengine: Add STM32 DMA driver
  ARM: dts: Add STM32 DMA support for STM32F429 MCU
  ARM: configs: Add STM32 DMA support in STM32 defconfig

 .../devicetree/bindings/dma/stm32-dma.txt  |   82 ++
 arch/arm/boot/dts/stm32f429.dtsi   |   31 +
 arch/arm/configs/stm32_defconfig   |2 +
 drivers/dma/Kconfig|   12 +
 drivers/dma/Makefile   |1 +
 drivers/dma/stm32-dma.c| 1148 
 6 files changed, 1276 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
 create mode 100644 drivers/dma/stm32-dma.c

-- 
1.9.1

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

Re: [PATCH 5/5] arm: dts: lpc32xx: add device node for the second pwm controller

[Vladimir Zapolskiy]

Hi Joachim,

On 14.10.2015 21:04, Joachim Eastwood wrote:
> Hi Vladimir,
> 
> On 13 October 2015 at 01:54, Vladimir Zapolskiy  wrote:
>> LPC32xx SoCs have two independent PWM controllers, they have different
>> clock parents, clock gates and even slightly different controls,
>> each of these two PWM controllers has one output channel. Due to
>> almost similar controls arranged in a row it is incorrectly assumed
>> that there is one PWM controller with two channels, fix this problem
>> in lpc32xx.dtsi, which at the moment prevents separate configuration
>> of different clock parents and gates for both PWM controllers.
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> ---
>>  arch/arm/boot/dts/lpc32xx.dtsi | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
>> index 929458d..f4d2a0e 100644
>> --- a/arch/arm/boot/dts/lpc32xx.dtsi
>> +++ b/arch/arm/boot/dts/lpc32xx.dtsi
>> @@ -286,9 +286,15 @@
>> status = "disabled";
>> };
>>
>> -   pwm: pwm@4005C000 {
>> +   pwm1: pwm@4005C000 {
>> compatible = "nxp,lpc3220-pwm";
>> -   reg = <0x4005C000 0x8>;
>> +   reg = <0x4005C000 0x4>;
>> +   status = "disabled";
>> +   };
>> +
>> +   pwm2: pwm@4005C004 {
>> +   compatible = "nxp,lpc3220-pwm";
>> +   reg = <0x4005C004 0x4>;
>> status = "disabled";
>> };
>> };
> 
> I am not really against your change, but...
> 
> What's wrong with a binding like the one below?
> pwm: pwm@0x4005c000 {
> compatible = "nxp,lpc3220-pwm";
> reg = <0x4005C000 0x8>;
> clocks =< CLK_PWM1,  CLK_PWM2>;
> clock-names = "pwm1", "pwm2";
> #pwm-cells = <3>;
> };
> 
> With two clocks and where the first pwm-cell would select either PWM1 or PWM2.
> 
> Seems like the driver only handle one clock, but should be fairly easy to fix.

I thought about it and IMHO it is a more complicated change in DTS (and
no doubts in the driver), which hides the structure of hardware. There
is no one PWM with two channels.

There are two independent PWMs, even control registers are different,
PWM2 can be programmed to output the internal interrupt status, and it
means that possibly in future I may want to describe one of the PWMs
with a different "compatible" property.

> Note: with your DT change you would also need to change the driver
> since it currently sets npwm to 2.
> 

It is done -- http://permalink.gmane.org/gmane.linux.pwm/2831

Thanks for review.

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv4 3/3] devicetree: Add led-backlight binding

[Tomi Valkeinen]

Hi Rob,

On 13/10/15 17:21, Rob Herring wrote:
> On Wed, Sep 30, 2015 at 4:32 AM, Tomi Valkeinen  wrote:
>> Add DT binding for led-backlight.
> 
> Please use get_maintainers.pl.

At some point I got feedback that the DT maintainers don't have time to
look at each individual driver binding, but rely on the subsystem
maintainers to handle them. Maybe I misunderstood that.

>> Signed-off-by: Tomi Valkeinen 
>> Cc: devicetree@vger.kernel.org
>> ---
>>  .../bindings/video/backlight/led-backlight.txt | 30 
>> ++
>>  1 file changed, 30 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/video/backlight/led-backlight.txt 
>> b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>> new file mode 100644
>> index ..d4621d7414bc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>> @@ -0,0 +1,30 @@
>> +led-backlight bindings
>> +
>> +Required properties:
>> +  - compatible: "led-backlight"
>> +  - leds: phandle to a led OF node [0]
> 
> Why do we need 2 levels of LED nodes?

Sorry, didn't get that. What do you mean with 2 levels?

>> +  - brightness-levels: Array of distinct LED brightness levels. These
>> +  are in the range from 0 to 255, passed to the LED class driver.
>> +  - default-brightness-level: the default brightness level (index into the
>> +  array defined by the "brightness-levels" property)
>> +
>> +Optional properties:
>> +  - power-supply: regulator for supply voltage
>> +  - enable-gpios: contains a single GPIO specifier for the GPIO which 
>> enables
>> +  and disables the backlight (see GPIO binding[1])
> 
> Why are all of these not part of the LED node pointed to by leds?

These are for the backlight, not for the LED chip. So "LED" here is a
chip that produces (most likely) a PWM signal, and "backlight" is the
collection of components that use the PWM to produce the backlight
itself, and use the power-supply and gpios.

> Describe the h/w, not what you want for a driver.

I think this describes the HW quite well. The LED chip works fine
without any of the properties here, and these are specific to the
backlight part of the board.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] iio: mma8452: support either of the available interrupt pins

[Mark Rutland]

On Wed, Oct 14, 2015 at 05:12:32PM +0200, Lars-Peter Clausen wrote:
> On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> [...]
> > +   if (irq1 > 0)
> > +   client->irq = irq1;
> 
> You must not overwrite client->irq, that field is manged by the I2C core and
> is supposed to be read only for device drivers.

Ok.

I think for the moment the simlpest thing to do would be to check which
of INT1 and INT2 match client->irq, and use that.

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

Re: [PATCH] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

[Masahiro Yamada]

2015-10-15 17:58 GMT+09:00 Masahiro Yamada :
> The IRQ signal from external devices on this board is connected to
> the XIRQ1 pin of the SoC.  The IRQ number should be 51, not 50.
>
> Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
> SoC/board support")
> Signed-off-by: Masahiro Yamada 
> ---
>
> Hi Olof and Arnd,
>
> Could you apply this simple fix for Linux 4.13, please?
> (if it is troublesome, I can wait until Linux 4.14-rc1.)
>
> Thanks
>


This patch turned out wrong.
I retract this one and will send v2 later.

Sorry.




-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: DT: STi: STiH418: Fix mmc0 clock configuration

[Maxime Coquelin]

On 08/24/2015 04:23 PM, Gabriel Fernandez wrote:

This patch configure correctly the MMC-0 clock for STiH418 platform.

Signed-off-by: Gabriel Fernandez 
Acked-by: Maxime Coquelin 
---
  arch/arm/boot/dts/stih418.dtsi | 6 ++
  1 file changed, 6 insertions(+)



Applied, thanks.

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

Re: [PATCH v3] iio: mma8452: support either of the available interrupt pins

[Mark Rutland]

On Thu, Oct 15, 2015 at 11:32:59AM +0200, Martin Kepplinger wrote:
> Am 2015-10-14 um 17:12 schrieb Lars-Peter Clausen:
> > On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> > [...]
> >> +  if (irq1 > 0)
> >> +  client->irq = irq1;
> > 
> > You must not overwrite client->irq, that field is manged by the I2C core and
> > is supposed to be read only for device drivers.
> >
> 
> I thought about it again and before I implement it, let me show you:
> 
> since interrupt-names would be "invented" anyways ("INT1", "INT2"),
> here's an idea for the bindings doc that would be a more long-term
> solution to implement:
> 
>   - interrupts: interrupt mapping for GPIO IRQ
> 
> These devices have two interrupt pins called INT1 and INT2 they
> can route their different interrupt sources to:

This being the case, the binding should only talk about INT1 and INT2.
The names might be "invented", but they describe the physical pins on
the device, and thus describe a physical property of the device.

> IRQ NameInterrupt SourceWired Pin
> -
> DATA_READY_1data ready  INT1
> DATA_READY_2INT2
> MOTION_1motion events   INT1
> MOTION_2INT2
> INT1all INT1
> INT2INT2
> 
>   - interrupt-names: should contain IRQ Names in the order in which they
>  were supplied in the interrupts property.
> 
>  Depending on how your chip is wired and what
>  interrupt sources should be handled by the driver,
>  choose one IRQ Name per Interrupt source, or
>  INT1/INT2 for all sources to one pin here.

The configuration of logical interrupts to those physical pins is a
choice that can be made at runtime, and should not live in the DT. It is
not a property of the hardware.

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

Re: [PATCH] ARM: shmobile: porter: add HS-USB DT support

[Sergei Shtylyov]

Hello.

On 10/15/2015 3:18 AM, Simon Horman wrote:


Enable HS-USB device  for the Porter board, defining the GPIO that the
driver should check  when probing (which is the ID output from MAX3355
OTG chip).

Note that there  will be pinctrl-related error messages if both internal
PCI  and  HS-USB drivers are enabled but they should be just ignored.

This patch is  analogous  to the commit 6f4f7156e0e6 (ARM: shmobile:
henninger: enable HS-USB) as there  are no differences between the
boards in this respect.

Signed-off-by: Sergei Shtylyov 


Thanks Sergei,

I have queued this up for v4.5.

I took the liberty of tweaking the changelog to address a complaint made
by Mr. Check Patch.


   Which means I forgot to run it again. Sorry about that. :-<


ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 6f4f7156e0e6 ("ARM: shmobile: henninger: enable HS-USB")'


   Keep forgetting about the now enforced quotes...

MBR, Sergei

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

[PATCH v3 2/4] dmaengine: Add STM32 DMA driver

[M'boumba Cedric Madianga]

This patch adds support for the STM32 DMA controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/Kconfig |   12 +
 drivers/dma/Makefile|1 +
 drivers/dma/stm32-dma.c | 1148 +++
 3 files changed, 1161 insertions(+)
 create mode 100644 drivers/dma/stm32-dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index af81a7a..b1a071b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -431,6 +431,18 @@ config STE_DMA40
help
  Support for ST-Ericsson DMA40 controller
 
+config STM32_DMA
+   bool "STMicroelectronics STM32 DMA support"
+   depends on ARCH_STM32
+   select DMA_ENGINE
+   select DMA_OF
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the on-chip DMA controller on STMicroelectronics
+ STM32 MCUs.
+ If you have a board based on such a MCU and wish to use DMA say Y or M
+ here.
+
 config S3C24XX_DMAC
tristate "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index ef9c099..2dd0a067 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
+obj-$(CONFIG_STM32_DMA) += stm32-dma.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
new file mode 100644
index 000..a047484
--- /dev/null
+++ b/drivers/dma/stm32-dma.c
@@ -0,0 +1,1148 @@
+/*
+ * Driver for STM32 DMA controller
+ *
+ * Inspired by dma-jz4740.c and tegra20-apb-dma.c
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virt-dma.h"
+
+#define STM32_DMA_LISR 0x /* DMA Low Int Status Reg */
+#define STM32_DMA_HISR 0x0004 /* DMA High Int Status Reg */
+#define STM32_DMA_LIFCR0x0008 /* DMA Low Int Flag 
Clear Reg */
+#define STM32_DMA_HIFCR0x000c /* DMA High Int Flag 
Clear Reg */
+#define STM32_DMA_TCI  BIT(5) /* Transfer Complete Interrupt */
+#define STM32_DMA_HTI  BIT(4) /* Half Transfer Interrupt */
+#define STM32_DMA_TEI  BIT(3) /* Transfer Error Interrupt */
+#define STM32_DMA_DMEI BIT(2) /* Direct Mode Error Interrupt */
+#define STM32_DMA_FEI  BIT(0) /* FIFO Error Interrupt */
+
+/* DMA Stream x Configuration Register */
+#define STM32_DMA_SCR(x)   (0x0010 + 0x18 * (x)) /* x = 0..7 */
+#define STM32_DMA_SCR_REQ(n)   ((n & 0x7) << 25)
+#define STM32_DMA_SCR_MBURST_MASK  GENMASK(24, 23)
+#define STM32_DMA_SCR_MBURST(n)((n & 0x3) << 23)
+#define STM32_DMA_SCR_PBURST_MASK  GENMASK(22, 21)
+#define STM32_DMA_SCR_PBURST(n)((n & 0x3) << 21)
+#define STM32_DMA_SCR_PL_MASK  GENMASK(17, 16)
+#define STM32_DMA_SCR_PL(n)((n & 0x3) << 16)
+#define STM32_DMA_SCR_MSIZE_MASK   GENMASK(14, 13)
+#define STM32_DMA_SCR_MSIZE(n) ((n & 0x3) << 13)
+#define STM32_DMA_SCR_PSIZE_MASK   GENMASK(12, 11)
+#define STM32_DMA_SCR_PSIZE(n) ((n & 0x3) << 11)
+#define STM32_DMA_SCR_PSIZE_GET(n) ((n & STM32_DMA_SCR_PSIZE_MASK) >> 11)
+#define STM32_DMA_SCR_DIR_MASK GENMASK(7, 6)
+#define STM32_DMA_SCR_DIR(n)   ((n & 0x3) << 6)
+#define STM32_DMA_SCR_CT   BIT(19) /* Target in double buffer */
+#define STM32_DMA_SCR_DBM  BIT(18) /* Double Buffer Mode */
+#define STM32_DMA_SCR_PINCOS   BIT(15) /* Peripheral inc offset size */
+#define STM32_DMA_SCR_MINC BIT(10) /* Memory increment mode */
+#define STM32_DMA_SCR_PINC BIT(9) /* Peripheral increment mode */
+#define STM32_DMA_SCR_CIRC BIT(8) /* Circular mode */
+#define STM32_DMA_SCR_PFCTRL   BIT(5) /* Peripheral Flow Controller */
+#define STM32_DMA_SCR_TCIE BIT(4) /* Transfer Cplete Int Enable*/
+#define STM32_DMA_SCR_HTIE BIT(3) /* Halft Transfer Int Enable*/
+#define STM32_DMA_SCR_TEIE BIT(2) /* Transfer Error Int Enable */
+#define STM32_DMA_SCR_DMEIEBIT(1) /* Direct Mode Err Int Enable */
+#define STM32_DMA_SCR_EN   BIT(0) /* Stream Enable */
+#define STM32_DMA_SCR_CFG_MASK (STM32_DMA_SCR_PINC \
+   | STM32_DMA_SCR_MINC \
+   

[PATCH v3 3/4] ARM: dts: Add STM32 DMA support for STM32F429 MCU

[M'boumba Cedric Madianga]

This patch adds STM32 DMA bindings for STM32F429.

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32f429.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d78a481..037eb29 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -174,6 +174,37 @@
reg = <0x40023800 0x400>;
clocks = <_hse>;
};
+
+   dma1: dma-controller@40026000 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026000 0x400>;
+   interrupts = <11>,
+<12>,
+<13>,
+<14>,
+<15>,
+<16>,
+<17>,
+<47>;
+   clocks = < 0 21>;
+   #dma-cells = <4>;
+   };
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = < 0 22>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   };
};
 };
 
-- 
1.9.1

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

[PATCH v3 1/4] dt-bindings: Document the STM32 DMA bindings

[M'boumba Cedric Madianga]

This patch adds documentation of device tree bindings for the STM32 dma
controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 .../devicetree/bindings/dma/stm32-dma.txt  | 82 ++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
b/Documentation/devicetree/bindings/dma/stm32-dma.txt
new file mode 100644
index 000..54d0326
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -0,0 +1,82 @@
+* STMicroelectronics STM32 DMA controller
+
+The STM32 DMA is a general-purpose direct memory access controller capable of
+supporting 8 independent DMA channels. Each channel can have up to 8 requests.
+
+Required properties:
+- compatible: Should be "st,stm32-dma"
+- reg: Should contain DMA registers location and length. This should include
+  all of the per-channel registers.
+- interrupts: Should contain all of the per-channel DMA interrupts ordering by
+  channel index.
+- clocks: Should contain the input clock of the DMA instance.
+- #dma-cells : Must be <4>. See DMA client paragraph for more details.
+
+Optional properties:
+- resets: Reference to a reset controller asserting the DMA controller
+- st,mem2mem: boolean; if defined, it indicates that the controller supports
+  memory-to-memory transfer
+
+Example:
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = <_hclk>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   resets = < 150>;
+   };
+
+* DMA client
+
+DMA clients connected to the STM32 DMA controller must use the format
+described in the dma.txt file, using a five-cell specifier for each
+channel: a phandle plus four integer cells.
+The four cells in order are:
+
+1. The channel id
+2. The request line number
+3. A 32bit mask specifying the DMA channel configuration which are device
+   dependent:
+  -bit 9: Peripheral Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 10: Memory Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 15: Peripheral Increment Offset Size
+   0x0: offset size is linked to the peripheral bus width
+   0x1: offset size is fixed to 4 (32-bit alignment)
+ -bit 16-17: Priority level
+   0x0: low
+   0x1: medium
+   0x2: high
+   0x3: very high
+5. A 32bit mask specifying the DMA FIFO threshold configuration which are 
device
+   dependent:
+ -bit 0-1: Fifo threshold
+   0x0: 1/4 full FIFO
+   0x1: 1/2 full FIFO
+   0x2: 3/4 full FIFO
+   0x3: full FIFO
+
+Example:
+
+   usart1: serial@40011000 {
+   compatible = "st,stm32-usart", "st,stm32-uart";
+   reg = <0x40011000 0x400>;
+   interrupts = <37>;
+   clocks = <_pclk2>;
+   dmas = < 2 4 0x10400 0x3>,
+  < 7 5 0x10200 0x3>;
+   dma-names = "rx", "tx";
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] thermal: mediatek: Add cpu power cooling model.

[dawei chien]

On Mon, 2015-10-12 at 18:26 +0100, Punit Agrawal wrote:
> Mark Rutland  writes:
> 
> > On Wed, Oct 07, 2015 at 08:22:40PM +0800, Dawei Chien wrote:
> >> From: "Dawei.Chien" 
> >> 
> >> This power model is base on Intelligent Power Allocation (IPA) technical,
> >> requires that the operating-points of the CPUs are registered using the
> >> kernel's opp library and the `cpufreq_frequency_table` is assigned to the
> >> `struct device` of the cpu MT8173.
> >> 
> >> Signed-off-by: Dawei.Chien 
> >> ---
> >> This patch is base on
> >> https://patchwork.kernel.org/patch/7034601/
> >> ---
> >>  drivers/cpufreq/mt8173-cpufreq.c |   97 
> >> +-
> >>  1 file changed, 86 insertions(+), 11 deletions(-)
> >> 
> >> diff --git a/drivers/cpufreq/mt8173-cpufreq.c 
> >> b/drivers/cpufreq/mt8173-cpufreq.c
> >> index 49caed2..9233ec5 100644
> >> --- a/drivers/cpufreq/mt8173-cpufreq.c
> >> +++ b/drivers/cpufreq/mt8173-cpufreq.c
> >> @@ -28,7 +28,8 @@
> >>  #define MAX_VOLT_SHIFT(20)
> >>  #define MAX_VOLT_LIMIT(115)
> >>  #define VOLT_TOL  (1)
> >> -
> >> +#define CAPACITANCE_CA53  (263)
> >> +#define CAPACITANCE_CA57  (530)
> >>  /*
> >>   * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU 
> >> DVFS
> >>   * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
> >> @@ -51,6 +52,72 @@ struct mtk_cpu_dvfs_info {
> >>bool need_voltage_tracking;
> >>  };
> >>  
> >> +struct mtk_cpu_static_power {
> >> +  unsigned long voltage;
> >> +  unsigned int power;
> >> +};
> >> +
> >> +/* measured by WA program. */
> >> +static const struct mtk_cpu_static_power mtk_ca53_static_power[] = {
> >> +  {859000, 43},
> >> +  {908000, 52},
> >> +  {983000, 86},
> >> +  {1009000, 123},
> >> +  {1028000, 138},
> >> +  {1083000, 172},
> >> +  {1109000, 180},
> >> +  {1125000, 192},
> >> +};
> >> +
> >> +/* measured by WA program. */
> >> +static const struct mtk_cpu_static_power mtk_ca57_static_power[] = {
> >> +  {828000, 72},
> >> +  {867000, 90},
> >> +  {927000, 156},
> >> +  {968000, 181},
> >> +  {1007000, 298},
> >> +  {1049000, 435},
> >> +  {1089000, 533},
> >> +  {1125000, 533},
> >> +};
> >
> > This should be described in the DT, rather than necessitating tonnes of
> > these tables in the kernel.
> 
> The above table is a simplification that is tying the static power of a
> device to a voltage (indirectly via frequency for ease of indexing
> perhaps).
> 
> We should definitely look at describing the static power model in the
> device tree - but it is not entirely clear what is the best model to
> use as basis for the device tree bindings.
> 
> Static power consumption depends on a few different parameters (silicon
> process, voltage, temperature, etc.). The relationship between them
> maybe non-linear and not all of these maybe significant for a given
> platform. e.g., for Juno, we are using a regression based on voltage and
> temperature which was deemed close enough (very subjective tbh).
> 
> On the other hand, dynamic power consumption is somewhat simpler and I
> have patches[0][1][2] enabling it's description in device tree. Your comments
> there would be very much appreciated.
> 
> As for this patch, I hope it can be moved to using the device tree when
> the bindings for static power are agreed upon. Although sub-optimal, I
> can't see any other way forward for now.
> 
> [0] http://thread.gmane.org/gmane.linux.kernel/2011466/focus=130373
> [1] http://thread.gmane.org/gmane.linux.kernel/2011466/focus=2011465
> [2] http://article.gmane.org/gmane.linux.drivers.sensors/37859

Hi Mark/Punit,
Thank you for your nice comments. I will resend this patch with device tree for 
dynamic/static power model,
and refer to Punit's patches, thank you.

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



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

[PATCH v2] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

[Masahiro Yamada]

The IRQ signal from external devices on this board is connected to
the XIRQ4 pin of the SoC.  The IRQ number should be 52, not 50.

Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
SoC/board support")
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - change IRQ to 52

 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 33963ac..f80f772 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -85,7 +85,7 @@
 };
 
  {
-   interrupts = <0 50 4>;
+   interrupts = <0 52 4>;
 };
 
  {
-- 
1.9.1

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

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync 
with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)


Tomeu Vizoso (20):
  driver core: handle -EPROBE_DEFER from bus_type.match()
  ARM: amba: Move reading of periphid to amba_match()
  of/platform: Point to struct device from device node
  of: add function to allow probing a device from a OF node
  gpio: Probe GPIO drivers on demand
  pinctrl: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c adapters and devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand
  driver core: Allow deferring probes until late init
  of/platform: Defer probes of registered devices

 drivers/amba/bus.c  | 88 +++--
 drivers/base/Kconfig| 18 
 drivers/base/dd.c   | 30 -
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  3 ++
 drivers/gpio/gpiolib-of.c   |  5 +++
 drivers/gpu/drm/drm_panel.c |  3 ++
 drivers/gpu/drm/tegra/dpaux.c   |  3 ++
 drivers/i2c/i2c-core.c  |  4 ++
 drivers/of/device.c | 61 +
 drivers/of/platform.c   | 30 -
 drivers/phy/phy-core.c  |  3 ++
 drivers/pinctrl/devicetree.c|  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c  |  3 ++
 drivers/regulator/core.c|  2 +
 drivers/usb/phy/phy.c   |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h  |  4 +-
 include/linux/of.h  |  1 +
 include/linux/of_device.h   |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] ARM: configs: Add STM32 DMA support in STM32 defconfig

[M'boumba Cedric Madianga]

This patch adds STM32 DMA support in stm32_defconfig file

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 4725fab..ec52505 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -54,6 +54,8 @@ CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_DMADEVICES=y
+CONFIG_STM32_DMA=y
 # CONFIG_FILE_LOCKING is not set
 # CONFIG_DNOTIFY is not set
 # CONFIG_INOTIFY_USER is not set
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/7] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

[Daniel Thompson]

On 14/10/15 21:07, Maxime Coquelin wrote:

Signed-off-by: Maxime Coquelin 
---
  include/dt-bindings/pinctrl/pinctrl-stm32.h |   12 +
  include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241 +++
  2 files changed, 1253 insertions(+)
  create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
  create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h 
b/include/dt-bindings/pinctrl/pinctrl-stm32.h
new file mode 100644
index 000..a2e7222
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
@@ -0,0 +1,12 @@
+#ifndef _DT_BINDINGS_PINCTRL_STM32_H
+#define _DT_BINDINGS_PINCTRL_STM32_H
+
+#define STM32_PIN_NO(x) ((x) << 8)
+#define STM32_GET_PIN_NO(x) ((x) >> 8)
+#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
+
+#define STM32_PIN_GPIO 0
+#define STM32_PIN_AF(x)((x) + 1)
+#define STM32_PIN_ANALOG   (STM32_PIN_AF(15) + 1)
+
+#endif /* _DT_BINDINGS_PINCTRL_STM32_H */
diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h 
b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
new file mode 100644
index 000..979e4eb
--- /dev/null
+++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
@@ -0,0 +1,1241 @@
+#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
+#define _DT_BINDINGS_STM32F429_PINFUNC_H
+
+#include 
+
+#define STM32F429_PA0_FUNC_GPIO (STM32_PIN_NO(0) | STM32_PIN_GPIO)
+#define STM32F429_PA0_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(0) | 
STM32_PIN_AF(1))


For the clock driver I was advised to get rid of this sort of "heroics" 
and expose raw numbers from the datasheet directly to DT bindings users.


Should the same logic apply to this *huge* collection of macros?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/7] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

[Daniel Thompson]

On 15/10/15 12:29, Maxime Coquelin wrote:

2015-10-15 13:14 GMT+02:00 Daniel Thompson :

On 14/10/15 21:07, Maxime Coquelin wrote:


Signed-off-by: Maxime Coquelin 
---
   include/dt-bindings/pinctrl/pinctrl-stm32.h |   12 +
   include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241
+++
   2 files changed, 1253 insertions(+)
   create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
   create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h
b/include/dt-bindings/pinctrl/pinctrl-stm32.h
new file mode 100644
index 000..a2e7222
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
@@ -0,0 +1,12 @@
+#ifndef _DT_BINDINGS_PINCTRL_STM32_H
+#define _DT_BINDINGS_PINCTRL_STM32_H
+
+#define STM32_PIN_NO(x) ((x) << 8)
+#define STM32_GET_PIN_NO(x) ((x) >> 8)
+#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
+
+#define STM32_PIN_GPIO 0
+#define STM32_PIN_AF(x)((x) + 1)
+#define STM32_PIN_ANALOG   (STM32_PIN_AF(15) + 1)
+
+#endif /* _DT_BINDINGS_PINCTRL_STM32_H */
diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
new file mode 100644
index 000..979e4eb
--- /dev/null
+++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
@@ -0,0 +1,1241 @@
+#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
+#define _DT_BINDINGS_STM32F429_PINFUNC_H
+
+#include 
+
+#define STM32F429_PA0_FUNC_GPIO (STM32_PIN_NO(0) | STM32_PIN_GPIO)
+#define STM32F429_PA0_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(0) |
STM32_PIN_AF(1))



For the clock driver I was advised to get rid of this sort of "heroics" and
expose raw numbers from the datasheet directly to DT bindings users.

Should the same logic apply to this *huge* collection of macros?


I'm open to change, I just took example on the Mediatek implementation.
Advantage is that checkpatch will be more silent, drawback is that it
will be a little harder to understand how these values are generated.
If we decide to change to raw values, then the DT Bindings
documentation will need to be more verbose on the way these values are
generated.


To be honest I was thinking about moaning about that anyway. Its pretty 
tough from the docs you have currently to figure out the encoding.


Does having header files really excuse us from documenting the bindings 
properly? ;-)



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

[PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Tomeu Vizoso]

When the DISP1 power domain is powered off, there's two clocks that need
to be temporarily reparented to OSC, and back to their original parents
when the domain is powered on again.

We expose these two clocks in the DT bindings so that the DT node of the
power domain can reference them.

Signed-off-by: Tomeu Vizoso 
Acked-by: Stephen Boyd 
---

Changes in v2:
- Reuse mout_aclk200_p
- Rename div_aclk300 as div_aclk300_disp

 drivers/clk/samsung/clk-exynos5250.c   | 14 +-
 include/dt-bindings/clock/exynos5250.h |  4 +++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 55b83c7ef878..5bebf8cb0d70 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -222,9 +222,13 @@ PNAME(mout_mpll_user_p)= { "fin_pll", "mout_mpll" };
 PNAME(mout_bpll_user_p)= { "fin_pll", "mout_bpll" };
 PNAME(mout_aclk166_p)  = { "mout_cpll", "mout_mpll_user" };
 PNAME(mout_aclk200_p)  = { "mout_mpll_user", "mout_bpll_user" };
+PNAME(mout_aclk300_p)  = { "mout_aclk300_disp1_mid",
+   "mout_aclk300_disp1_mid1" };
 PNAME(mout_aclk400_p)  = { "mout_aclk400_g3d_mid", "mout_gpll" };
 PNAME(mout_aclk200_sub_p) = { "fin_pll", "div_aclk200" };
 PNAME(mout_aclk266_sub_p) = { "fin_pll", "div_aclk266" };
+PNAME(mout_aclk300_sub_p) = { "fin_pll", "div_aclk300_disp" };
+PNAME(mout_aclk300_disp1_mid1_p) = { "mout_vpll", "mout_cpll" };
 PNAME(mout_aclk333_sub_p) = { "fin_pll", "div_aclk333" };
 PNAME(mout_aclk400_isp_sub_p) = { "fin_pll", "div_aclk400_isp" };
 PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
@@ -303,9 +307,13 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
 */
MUX(0, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+   MUX(0, "mout_aclk300_disp1_mid", mout_aclk200_p, SRC_TOP0, 14, 1),
+   MUX(0, "mout_aclk300", mout_aclk300_p, SRC_TOP0, 15, 1),
MUX(0, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(0, "mout_aclk400_g3d_mid", mout_aclk200_p, SRC_TOP0, 20, 1),
 
+   MUX(0, "mout_aclk300_disp1_mid1", mout_aclk300_disp1_mid1_p, SRC_TOP1,
+   8, 1),
MUX(0, "mout_aclk400_isp", mout_aclk200_p, SRC_TOP1, 24, 1),
MUX(0, "mout_aclk400_g3d", mout_aclk400_p, SRC_TOP1, 28, 1),
 
@@ -316,7 +324,10 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
MUX(0, "mout_bpll_user", mout_bpll_user_p, SRC_TOP2, 24, 1),
MUX(CLK_MOUT_GPLL, "mout_gpll", mout_gpll_p, SRC_TOP2, 28, 1),
 
-   MUX(0, "mout_aclk200_disp1_sub", mout_aclk200_sub_p, SRC_TOP3, 4, 1),
+   MUX(CLK_MOUT_ACLK200_DISP1_SUB, "mout_aclk200_disp1_sub",
+   mout_aclk200_sub_p, SRC_TOP3, 4, 1),
+   MUX(CLK_MOUT_ACLK300_DISP1_SUB, "mout_aclk300_disp1_sub",
+   mout_aclk300_sub_p, SRC_TOP3, 6, 1),
MUX(0, "mout_aclk266_gscl_sub", mout_aclk266_sub_p, SRC_TOP3, 8, 1),
MUX(0, "mout_aclk_266_isp_sub", mout_aclk266_sub_p, SRC_TOP3, 16, 1),
MUX(0, "mout_aclk_400_isp_sub", mout_aclk400_isp_sub_p,
@@ -392,6 +403,7 @@ static struct samsung_div_clock exynos5250_div_clks[] 
__initdata = {
DIV(0, "div_aclk333", "mout_aclk333", DIV_TOP0, 20, 3),
DIV(0, "div_aclk400_g3d", "mout_aclk400_g3d", DIV_TOP0,
24, 3),
+   DIV(0, "div_aclk300_disp", "mout_aclk300", DIV_TOP0, 28, 3),
 
DIV(0, "div_aclk400_isp", "mout_aclk400_isp", DIV_TOP1, 20, 3),
DIV(0, "div_aclk66_pre", "mout_mpll_user", DIV_TOP1, 24, 3),
diff --git a/include/dt-bindings/clock/exynos5250.h 
b/include/dt-bindings/clock/exynos5250.h
index 8183d1c237d9..15508adcdfde 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -173,8 +173,10 @@
 /* mux clocks */
 #define CLK_MOUT_HDMI  1024
 #define CLK_MOUT_GPLL  1025
+#define CLK_MOUT_ACLK200_DISP1_SUB 1026
+#define CLK_MOUT_ACLK300_DISP1_SUB 1027
 
 /* must be greater than maximal clock id */
-#define CLK_NR_CLKS1026
+#define CLK_NR_CLKS1028
 
 #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5250_H */
-- 
2.5.0

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

[PATCH v2 0/2] Fix display on second resume on 5250-snow

[Tomeu Vizoso]

Hi,

as discussed in [0], currently on the second resume from memory the
display is broken on Snow boards (ARM Samsung Series 3 Chromebook).

The reason is that on resume the contents of register SRC_TOP3 aren't
what the kernel thinks they are because the HW (or FW) is doing some
clock reparenting beneath our feet.

This series tasks the kernel to do the reparenting itself so that the HW
state always matches the kernel's internal state.

Thanks,

Tomeu

[0] http://lkml.kernel.org/g/561cdc33.7050...@collabora.com

Changes in v2:
- Reuse mout_aclk200_p
- Rename div_aclk300 as div_aclk300_disp

Tomeu Vizoso (2):
  clk: samsung: exynos5250: Add DISP1 clocks
  ARM: dts: exynos5250: Add clocks to DISP1 domain

 arch/arm/boot/dts/exynos5250.dtsi  |  4 
 drivers/clk/samsung/clk-exynos5250.c   | 14 +-
 include/dt-bindings/clock/exynos5250.h |  4 +++-
 3 files changed, 20 insertions(+), 2 deletions(-)

-- 
2.5.0

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

[PATCH v2 2/2] ARM: dts: exynos5250: Add clocks to DISP1 domain

[Tomeu Vizoso]

Adds to the node of the DISP1 power domain the two clocks that need to
be reparented while the domain is powered off:
CLK_MOUT_ACLK200_DISP1_SUB and CLK_MOUT_ACLK300_DISP1_SUB.

Otherwise the state is unknown at power up and the mixer's clocks are
all messed up.

Signed-off-by: Tomeu Vizoso 
Link: http://lkml.kernel.org/g/561cdc33.7050...@collabora.com
---


 arch/arm/boot/dts/exynos5250.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index b24610ea8c2a..88b9cf5f226f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -130,6 +130,10 @@
compatible = "samsung,exynos4210-pd";
reg = <0x100440A0 0x20>;
#power-domain-cells = <0>;
+   clocks = < CLK_FIN_PLL>,
+< CLK_MOUT_ACLK200_DISP1_SUB>,
+< CLK_MOUT_ACLK300_DISP1_SUB>;
+   clock-names = "oscclk", "clk0", "clk1";
};
 
clock: clock-controller@1001 {
-- 
2.5.0

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

Re: [PATCH 03/25] scsi: hisi_sas: add initial bare driver

[Xinwei Kong]

On 2015/10/15 17:23, John Garry wrote:

On 15/10/2015 09:49, Xinwei Kong wrote:



On 2015/10/12 23:20, John Garry wrote:

This patch adds the initial bare driver for the HiSilicon
SAS HBA. The driver includes no HW interaction, but only
the changes to build and load the driver module.

The HBA is a platform device.

Signed-off-by: John Garry 
---
  drivers/scsi/Kconfig  |  1 +
  drivers/scsi/Makefile |  1 +
  drivers/scsi/hisi_sas/Kconfig |  5 +++
  drivers/scsi/hisi_sas/Makefile|  2 ++
  drivers/scsi/hisi_sas/hisi_sas.h  | 24 +++
  drivers/scsi/hisi_sas/hisi_sas_init.c | 58 
+++

  6 files changed, 91 insertions(+)
  create mode 100644 drivers/scsi/hisi_sas/Kconfig
  create mode 100644 drivers/scsi/hisi_sas/Makefile
  create mode 100644 drivers/scsi/hisi_sas/hisi_sas.h
  create mode 100644 drivers/scsi/hisi_sas/hisi_sas_init.c

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 95f7a76..5c345f9 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1774,5 +1774,6 @@ source "drivers/scsi/pcmcia/Kconfig"
  source "drivers/scsi/device_handler/Kconfig"

  source "drivers/scsi/osd/Kconfig"
+source "drivers/scsi/hisi_sas/Kconfig"

  endmenu
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 1a8c9b5..03c30de 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_CHR_DEV_SCH)+= ch.o
  obj-$(CONFIG_SCSI_ENCLOSURE)+= ses.o

  obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
+obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas/

  # This goes last, so that "real" scsi devices probe earlier
  obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o
diff --git a/drivers/scsi/hisi_sas/Kconfig 
b/drivers/scsi/hisi_sas/Kconfig

new file mode 100644
index 000..a7f47a2
--- /dev/null
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -0,0 +1,5 @@
+config SCSI_HISI_SAS
+tristate "HiSilicon SAS"
+select SCSI_SAS_LIBSAS
+help
+This driver supports HiSilicon's SAS HBA
diff --git a/drivers/scsi/hisi_sas/Makefile 
b/drivers/scsi/hisi_sas/Makefile

new file mode 100644
index 000..63c3c4d
--- /dev/null
+++ b/drivers/scsi/hisi_sas/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas.o
+hisi_sas-y+= hisi_sas_init.o
diff --git a/drivers/scsi/hisi_sas/hisi_sas.h 
b/drivers/scsi/hisi_sas/hisi_sas.h

new file mode 100644
index 000..50204a2
--- /dev/null
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program 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.
+ *
+ */
+
+#ifndef _HISI_SAS_H_
+#define _HISI_SAS_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+

why place some "include" head in .h file rather than .c file?

This is private header within the module, which:
- makes the code more concise
- relocate functions within c files is cleaner
- easier to change the kernel APIs we use in the module

this  .h file  wil be included by  "hisi_sas_main.c"   and 
"hisi_sas_init.c" file.
if all "include" term can't be used in both  ".c" file.  When you build 
this code,

it will add  some burden work.

Thank you
xinwei

+#define DRV_NAME "hisi_sas"
+#define DRV_VERSION "v1.0"
+
+#endif
diff --git a/drivers/scsi/hisi_sas/hisi_sas_init.c 
b/drivers/scsi/hisi_sas/hisi_sas_init.c

new file mode 100644
index 000..dd83430
--- /dev/null
+++ b/drivers/scsi/hisi_sas/hisi_sas_init.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program 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.
+ *
+ */
+
+#include "hisi_sas.h"
+
+static const struct of_device_id sas_of_match[] = {
+{ .compatible = "hisilicon,sas-controller-v1",},
+{},
+};
+MODULE_DEVICE_TABLE(of, sas_of_match);
+static int hisi_sas_probe(struct platform_device *pdev)
+{
+
+return 0;
+}
+
+static int hisi_sas_remove(struct platform_device *pdev)
+{
+return 0;
+}
+
+static struct platform_driver hisi_sas_driver = {
+.probe = hisi_sas_probe,
+.remove = hisi_sas_remove,
+.driver = {
+.name = DRV_NAME,
+.of_match_table = sas_of_match,
+},
+};
+
+static __init int hisi_sas_init(void)
+{
+pr_info("hisi_sas: driver version %s\n", DRV_VERSION);
+
+return platform_driver_register(_sas_driver);
+}
+
+static __exit void hisi_sas_exit(void)
+{
+platform_driver_unregister(_sas_driver);
+}
+
+module_init(hisi_sas_init);
+module_exit(hisi_sas_exit);
+
+MODULE_VERSION(DRV_VERSION);

Re: [PATCH 3/4] mmc: mediatek: Add tune support

[Sascha Hauer]

On Thu, Oct 15, 2015 at 10:46:20AM +0800, Chaotian Jing wrote:
> On Wed, 2015-10-14 at 12:05 +0200, Ulf Hansson wrote:
> > On 13 October 2015 at 11:37, Chaotian Jing  
> > wrote:
> > > Add CMD19/CMD21 support for EMMC/SD/SDIO tuning
> > > Add HS400 mode support
> > >
> > > Signed-off-by: Chaotian Jing 
> > > ---
> > >  drivers/mmc/host/mtk-sd.c | 359 
> > > ++
> > >  1 file changed, 332 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > > index b2e89d3..f12a50a 100644
> > > --- a/drivers/mmc/host/mtk-sd.c
> > > +++ b/drivers/mmc/host/mtk-sd.c
> > > @@ -26,6 +26,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > >  #include 
> > > @@ -64,6 +65,7 @@
> > >  #define SDC_RESP20x48
> > >  #define SDC_RESP30x4c
> > >  #define SDC_BLK_NUM  0x50
> > > +#define EMMC_IOCON   0x7c
> > >  #define SDC_ACMD_RESP0x80
> > >  #define MSDC_DMA_SA  0x90
> > >  #define MSDC_DMA_CTRL0x98
> > > @@ -71,6 +73,8 @@
> > >  #define MSDC_PATCH_BIT   0xb0
> > >  #define MSDC_PATCH_BIT1  0xb4
> > >  #define MSDC_PAD_TUNE0xec
> > > +#define PAD_DS_TUNE  0x188
> > > +#define EMMC50_CFG0  0x208
> > >
> > >  
> > > /*--*/
> > >  /* Register Mask 
> > >*/
> > > @@ -87,6 +91,7 @@
> > >  #define MSDC_CFG_CKSTB  (0x1 << 7) /* R  */
> > >  #define MSDC_CFG_CKDIV  (0xff << 8)/* RW */
> > >  #define MSDC_CFG_CKMOD  (0x3 << 16)/* RW */
> > > +#define MSDC_CFG_HS400_CK_MODE  (0x1 << 18)/* RW */
> > >
> > >  /* MSDC_IOCON mask */
> > >  #define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
> > > @@ -204,6 +209,17 @@
> > >  #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29)  /* RW */
> > >  #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
> > >
> > > +#define MSDC_PAD_TUNE_DATRRDLY   (0x1f <<  8)  /* RW */
> > > +#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16)  /* RW */
> > > +
> > > +#define PAD_DS_TUNE_DLY1 (0x1f << 2)   /* RW */
> > > +#define PAD_DS_TUNE_DLY2 (0x1f << 7)   /* RW */
> > > +#define PAD_DS_TUNE_DLY3 (0x1f << 12)  /* RW */
> > > +
> > > +#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
> > > +#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3)   /* RW */
> > > +#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4)   /* RW */
> > > +
> > >  #define REQ_CMD_EIO  (0x1 << 0)
> > >  #define REQ_CMD_TMO  (0x1 << 1)
> > >  #define REQ_DAT_ERR  (0x1 << 2)
> > > @@ -219,6 +235,7 @@
> > >  #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
> > >  #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
> > >
> > > +#define DELAY_MAX  32 /* PAD dalay cells */
> > 
> > /s/dalay/delay
> > 
> > Can we have some more explaination around this define. Perhaps a more
> > self-explaining name would be enough.-
> 
> This is the max step of the pad delay cells, our hardware use 5bits to
> describe the pad delay.
> will change it to
> #define PAD_DELAY_MAX 32
> > >  
> > > /*--*/
> > >  /* Descriptor Structure  
> > >*/
> > >  
> > > /*--*/
> > > @@ -265,6 +282,14 @@ struct msdc_save_para {
> > > u32 pad_tune;
> > > u32 patch_bit0;
> > > u32 patch_bit1;
> > > +   u32 pad_ds_tune;
> > > +   u32 emmc50_cfg0;
> > > +};
> > > +
> > > +struct msdc_delay_phase {
> > > +   u8 maxlen;
> > > +   u8 start;
> > > +   u8 final_phase;
> > >  };
> > >
> > >  struct msdc_host {
> > > @@ -293,12 +318,15 @@ struct msdc_host {
> > > int irq;/* host interrupt */
> > >
> > > struct clk *src_clk;/* msdc source clock */
> > > +   struct clk *src_clk_parent; /* src_clk's parent */
> > > +   struct clk *hs400_src;  /* 400Mhz source clock */
> > 
> > Hmm, so you need to control the upper level clocks. Can you elaborate
> > on why this is needed?
> > 
> hs400 is DDR200, in our host design, if the mode is DDR(HS400), if want
> to get 200Mhz mmc bus clock frequency, the minimum source clock is
> double of the mmc bus clock, So, we need it for HS400 mode with 200Mhz
> bus clock.
> > > struct clk *h_clk;  /* msdc h_clk */
> > > u32 mclk;   /* mmc subsystem clock frequency */
> > > u32 src_clk_freq;   /* source clock frequency */
> > > u32 sclk;   /* SD/MS bus clock frequency */
> > > -   bool ddr;
> > > +   unsigned char timing;
> > > bool vqmmc_enabled;
> > > +   u32 hs400_ds_delay;
> > > struct msdc_save_para save_para; /* used when gate HCLK */
> > >  

Re: [PATCH 3/5] MIPS: dt: xilfpga: Add xilfpga device tree files.

[James Hogan]

On Wed, Oct 14, 2015 at 01:51:55PM +0100, Zubair Lutfullah Kakakhel wrote:
> Signed-off-by: Zubair Lutfullah Kakakhel 

Any chance of a little more explanation, other than the subject line?

> ---
>  arch/mips/boot/dts/Makefile|  1 +
>  arch/mips/boot/dts/xilfpga/Makefile|  9 ++
>  arch/mips/boot/dts/xilfpga/microAptiv.dtsi | 21 +
>  arch/mips/boot/dts/xilfpga/nexys4ddr.dts   | 47 
> ++
>  4 files changed, 78 insertions(+)
>  create mode 100644 arch/mips/boot/dts/xilfpga/Makefile
>  create mode 100644 arch/mips/boot/dts/xilfpga/microAptiv.dtsi
>  create mode 100644 arch/mips/boot/dts/xilfpga/nexys4ddr.dts
> 
> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> index 778a340..0571ef7 100644
> --- a/arch/mips/boot/dts/Makefile
> +++ b/arch/mips/boot/dts/Makefile
> @@ -6,6 +6,7 @@ dts-dirs  += mti
>  dts-dirs += netlogic
>  dts-dirs += qca
>  dts-dirs += ralink
> +dts-dirs += xilfpga
>  
>  obj-y:= $(addsuffix /, $(dts-dirs))
>  
> diff --git a/arch/mips/boot/dts/xilfpga/Makefile 
> b/arch/mips/boot/dts/xilfpga/Makefile
> new file mode 100644
> index 000..913a752
> --- /dev/null
> +++ b/arch/mips/boot/dts/xilfpga/Makefile
> @@ -0,0 +1,9 @@
> +dtb-$(CONFIG_XILFPGA_NEXYS4DDR)  += nexys4ddr.dtb
> +
> +obj-y+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
> +
> +# Force kbuild to make empty built-in.o if necessary
> +obj- += dummy.o
> +
> +always   := $(dtb-y)
> +clean-files  := *.dtb *.dtb.S
> diff --git a/arch/mips/boot/dts/xilfpga/microAptiv.dtsi 
> b/arch/mips/boot/dts/xilfpga/microAptiv.dtsi
> new file mode 100644
> index 000..81d518e
> --- /dev/null
> +++ b/arch/mips/boot/dts/xilfpga/microAptiv.dtsi
> @@ -0,0 +1,21 @@
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "img,xilfpga";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "mips,m14Kc";
> + clocks  = <>;
> + reg = <0>;
> + };
> + };
> +
> + ext: ext {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> +};
> diff --git a/arch/mips/boot/dts/xilfpga/nexys4ddr.dts 
> b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
> new file mode 100644
> index 000..e225ae7
> --- /dev/null
> +++ b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
> @@ -0,0 +1,47 @@
> +/dts-v1/;
> +
> +#include "microAptiv.dtsi"
> +
> +/ {
> + compatible = "img,xilfpga";

You can have more than one compatible string, separated by commas. Does
it make sense to have one that describes the specific system first
(nexys4ddr??) in addition to the generic xilfpga one? That way software
can still distinguish if it becomes necessary.

> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x07ff>;

I think the second cell is size, not end address, so it should
presumably be 0x0800?

> + };
> +
> + cpuintc: interrupt-controller@0 {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + axi_gpio: gpio@1060 {
> + #gpio-cells = <1>;
> + compatible = "xlnx,xps-gpio-1.00.a";
> + gpio-controller;
> + reg = < 0x1060 0x1 >;

Inconsistent whitespace between < > compared to other properties.

> + xlnx,all-inputs = <0x0>;
> + xlnx,dout-default = <0x0>;
> + xlnx,gpio-width = <0x16>;
> + xlnx,interrupt-present = <0x0>;
> + xlnx,is-dual = <0x0>;
> + xlnx,tri-default = <0x>;
> + } ;
> +
> + axi_uart16550: serial@1040 {
> + compatible = "ns16550a";
> + reg = <0x1040 0x1>;
> +
> + reg-shift = <2>;
> + reg-offset = <0x1000>;
> +
> + clock-frequency = <5000>;

I guess the binding for that device already exists, but is it worth
extending it to take a clock node reference instead of a hardcoded
frequency (I'm guessing ext by the frequency and choice of clocks)?

> + status = "okay";

I don't think you normally need that unless you describe e.g. SoC
peripheral hardware that might not be brought out by the board, in which
case you'd say its disabled in the SoC dtsi file, but enable it at the
board level, which doesn't seem to be happening here.

Cheers
James

> + };
> +};
> +
> + {
> + clock-frequency = <5000>;
> +};
> -- 
> 1.9.1
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH v6 0/5] Add DT support for netxbig LEDs

[Gregory CLEMENT]

Hi Jacek,
 
 On ven., oct. 09 2015, Jacek Anaszewski  wrote:

> On 09/26/2015 11:02 PM, Simon Guinot wrote:
>> Hello,

[..]
>>
>> Simon Guinot (5):
>>leds: netxbig: add device tree binding
>>ARM: Kirkwood: add LED DT entries for netxbig boards
>>ARM: mvebu: remove static LED setup for netxbig boards
>>leds: netxbig: convert to use the devm_ functions
>>leds: netxbig: set led_classdev max_brightness
>>
>>   .../devicetree/bindings/gpio/netxbig-gpio-ext.txt  |  22 ++
>>   .../devicetree/bindings/leds/leds-netxbig.txt  |  92 ++
>>   arch/arm/boot/dts/kirkwood-net5big.dts |  60 
>>   arch/arm/boot/dts/kirkwood-netxbig.dtsi|  80 +
>>   arch/arm/mach-mvebu/Kconfig|   7 -
>>   arch/arm/mach-mvebu/Makefile   |   1 -
>>   arch/arm/mach-mvebu/board.h|  21 --
>>   arch/arm/mach-mvebu/kirkwood.c |   4 -
>>   arch/arm/mach-mvebu/netxbig.c  | 191 
>>   drivers/leds/leds-netxbig.c| 336 
>> -
>>   include/dt-bindings/leds/leds-netxbig.h|  18 ++
>>   .../linux/platform_data/leds-kirkwood-netxbig.h|   1 +
>>   12 files changed, 531 insertions(+), 302 deletions(-)
>>   create mode 100644 
>> Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
>>   create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
>>   delete mode 100644 arch/arm/mach-mvebu/board.h
>>   delete mode 100644 arch/arm/mach-mvebu/netxbig.c
>>   create mode 100644 include/dt-bindings/leds/leds-netxbig.h
>>
>
> Since no comment regarding DT bindings has appeared for a long time,
> I decided to merge the patch set without DT maintainer's ack, thanks.

it is a good news that this series will be finally merged. However did
you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?

Thanks,

Gregory

>
> -- 
> Best Regards,
> Jacek Anaszewski

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/25] scsi: hisi_sas: add initial bare driver

[zhangfei]

On 10/15/2015 05:23 PM, John Garry wrote:

On 15/10/2015 09:49, Xinwei Kong wrote:






+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program 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.



+MODULE_VERSION(DRV_VERSION);
+MODULE_LICENSE("GPL");

V2

Can add. We do say in the header that it is v2.


No, should use MODULE_LICENSE("GPL");

include/linux/module.h

/*
 * The following license idents are currently accepted as indicating free
 * software modules
 *
 *  "GPL"   [GNU Public License v2 or later]
 *  "GPL v2"[GNU Public License v2]

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

Re: [PATCH v3] iio: mma8452: support either of the available interrupt pins

[Martin Kepplinger]

Am 2015-10-14 um 17:12 schrieb Lars-Peter Clausen:
> On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> [...]
>> +if (irq1 > 0)
>> +client->irq = irq1;
> 
> You must not overwrite client->irq, that field is manged by the I2C core and
> is supposed to be read only for device drivers.
>

I thought about it again and before I implement it, let me show you:

since interrupt-names would be "invented" anyways ("INT1", "INT2"),
here's an idea for the bindings doc that would be a more long-term
solution to implement:

  - interrupts: interrupt mapping for GPIO IRQ

These devices have two interrupt pins called INT1 and INT2 they
can route their different interrupt sources to:

IRQ NameInterrupt SourceWired Pin
-
DATA_READY_1data ready  INT1
DATA_READY_2INT2
MOTION_1motion events   INT1
MOTION_2INT2
INT1all INT1
INT2INT2

  - interrupt-names: should contain IRQ Names in the order in which they
 were supplied in the interrupts property.

 Depending on how your chip is wired and what
 interrupt sources should be handled by the driver,
 choose one IRQ Name per Interrupt source, or
 INT1/INT2 for all sources to one pin here.

Example 1:

mma8453fc@1d {
compatible = "fsl,mma8453";
reg = <0x1d>;
interrupt-parent = <>;
interrupts = <5 0>;
interrupt-names = "INT2"; // interrupt pin wired to INT2
};

Example 2:

mma8453fc@1d {
compatible = "fsl,mma8453";
reg = <0x1d>;
interrupt-parent = <>;
interrupts = <4 0>, <5 0>;
/* data ready comes from INT2, motion events from INT1 */
interrupt-names = "DATA_READY_2", "MOTION_1";
};

What do you think?

thanks
   martin

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

[PATCH] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

[Masahiro Yamada]

The IRQ signal from external devices on this board is connected to
the XIRQ1 pin of the SoC.  The IRQ number should be 51, not 50.

Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
SoC/board support")
Signed-off-by: Masahiro Yamada 
---

Hi Olof and Arnd,

Could you apply this simple fix for Linux 4.13, please?
(if it is troublesome, I can wait until Linux 4.14-rc1.)

Thanks



 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 33963ac..3a6f1f6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -85,7 +85,7 @@
 };
 
  {
-   interrupts = <0 50 4>;
+   interrupts = <0 51 4>;
 };
 
  {
-- 
1.9.1

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

Re: [PATCH 3/4] mmc: mediatek: Add tune support

[Ulf Hansson]

[...]

>> >
>> > struct clk *src_clk;/* msdc source clock */
>> > +   struct clk *src_clk_parent; /* src_clk's parent */
>> > +   struct clk *hs400_src;  /* 400Mhz source clock */
>>
>> Hmm, so you need to control the upper level clocks. Can you elaborate
>> on why this is needed?
>>
> hs400 is DDR200, in our host design, if the mode is DDR(HS400), if want
> to get 200Mhz mmc bus clock frequency, the minimum source clock is
> double of the mmc bus clock, So, we need it for HS400 mode with 200Mhz
> bus clock.

Thanks for clarifying.

[...]

 > flags = readl(host->base + MSDC_INTEN);
>> > sdr_clr_bits(host->base + MSDC_INTEN, flags);
>> > -   if (ddr) { /* may need to modify later */
>> > -   mode = 0x2; /* ddr mode and use divisor */
>> > +   sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
>> > +   if (timing == MMC_TIMING_UHS_DDR50 ||
>> > +   timing == MMC_TIMING_MMC_DDR52 ||
>>
>> So, no support for HS200?
>>
> HS200 is the same with other SDR modes, so it will be handled at else..

Okay, nice!

So, your the driver currently supports HS200, but without need for tuning!?

[...]

>> > +static struct msdc_delay_phase get_best_delay(u32 delay)
>> > +{
>> > +   int start = 0, len = 0;
>> > +   int start_final = 0, len_final = 0;
>> > +   u8 final_phase = 0xff;
>> > +   struct msdc_delay_phase delay_phase;
>> > +
>> > +   if (delay == 0) {
>> > +   pr_err("phase error: [map:%x]\n", delay);
>>
>> Please use dev_err|warn|dbg|info instead.
>>
> As you know, this function is just only parse the argument "u32 delay",
> it do not bind with any device.

You may just add a msdc_host * as a parameter to the function, that
would solve this.

[...]

>> > +static int msdc_send_tuning(struct mmc_host *host, u32 opcode, int 
>> > *cmd_error)
>>
>> I think you can remove this function and use mmc_send_tuning() instead.
> Hmm, I also noticed that there was a mmc_send_tuning, but, I need to get
> the cmd_error when tune cmd response, in this case, do not care the data
> error.

Well, if you need to extend the mmc_send_tuning() API to suite your
needs, let's do that instead of duplicating code.

>>
>> > +{
>> > +   struct mmc_request mrq = {NULL};
>> > +   struct mmc_command cmd = {0};
>> > +   struct mmc_data data = {0};
>> > +   struct scatterlist sg;
>> > +   struct mmc_ios *ios = >ios;
>> > +   int size, err = 0;
>> > +   u8 *data_buf;
>> > +
>> > +   if (ios->bus_width == MMC_BUS_WIDTH_8)
>> > +   size = 128;
>> > +   else if (ios->bus_width == MMC_BUS_WIDTH_4)
>> > +   size = 64;
>> > +   else
>> > +   return -EINVAL;
>> > +
>> > +   data_buf = kzalloc(size, GFP_KERNEL);
>> > +   if (!data_buf)
>> > +   return -ENOMEM;
>> > +
>> > +   mrq.cmd = 
>> > +   mrq.data = 
>> > +
>> > +   cmd.opcode = opcode;
>> > +   cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
>> > +
>> > +   data.blksz = size;
>> > +   data.blocks = 1;
>> > +   data.flags = MMC_DATA_READ;
>> > +
>> > +   /*
>> > +* According to the tuning specs, Tuning process
>> > +* is normally shorter 40 executions of CMD19,
>> > +* and timeout value should be shorter than 150 ms
>> > +*/
>> > +   data.timeout_ns = 150 * NSEC_PER_MSEC;
>> > +
>> > +   data.sg = 
>> > +   data.sg_len = 1;
>> > +   sg_init_one(, data_buf, size);
>> > +
>> > +   mmc_wait_for_req(host, );
>> > +
>> > +   if (cmd_error)
>> > +   *cmd_error = cmd.error;
>> > +
>> > +   if (cmd.error) {
>> > +   err = cmd.error;
>> > +   goto out;
>> > +   }
>> > +
>> > +   if (data.error) {
>> > +   err = data.error;
>> > +   goto out;
>> > +   }
>> > +
>> > +out:
>> > +   kfree(data_buf);
>> > +   return err;
>> > +}
>> > +

[...]

>> > +   host->src_clk_parent = clk_get_parent(host->src_clk);
>>
>> Don't you need to check the return value here?
>>
> will check it.
>> > +   host->hs400_src = devm_clk_get(>dev, "400mhz");
>>
>> That's a really weird conid for a clock. If it's not too late to
>> change, please do that!
>>
>> > +   if (IS_ERR(host->hs400_src)) {
>> > +   dev_dbg(>dev, "Cannot find 400mhz at dts!\n");
>> > +   } else if (clk_set_parent(host->src_clk_parent, host->hs400_src) < 
>> > 0) {
>> > +   dev_err(host->dev, "Failed to set 400mhz source clock!\n");
>> > +   ret = -EINVAL;
>>
>> I think it seems more apropriate to use the return value from
>> clk_set_parent() instead of inventing your own return value.
>>
> OK.
>> > +   goto host_free;
>> > +   }
>>
>> It seems like you don't need to store the src_clk_parent and the
>> hs400_src in the host struct, as you are only using it during
>> ->probe().
> OK,will remove the member src_clk.

According to your earlier 

Re: [PATCH 3/3] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Lee Jones]

On Wed, 14 Oct 2015, Charles Keepax wrote:

> Binding documentation has been added in new subsystem specific binding
> documents. This patch removes the now duplicate documentation from the
> MFD documentation. Also whilst we are at it add a missing maintainers
> entry for the MFD binding document.
> 
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |   30 ++--
>  MAINTAINERS   |1 +
>  2 files changed, 4 insertions(+), 27 deletions(-)

Nice.  For my own reference:

  Acked-by: Lee Jones 

Once everyone is happy with the other two patches, I'll pick this.

> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..077c4fe 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -30,21 +30,9 @@ Required properties:
>- #gpio-cells : Must be 2. The first cell is the pin number and the
>  second cell is used to specify optional parameters (currently unused).
>  
> -  - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device,
> -as covered in Documentation/devicetree/bindings/regulator/regulator.txt
> -
> -  - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102,
> -wm5110, wm8280, wm8998, wm1814)
> -
> -  - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102,
> -wm5110, wm8280, wm8998, wm1814)
> -
> -  - SPKVDD-supply : Speaker driver power supply (wm8997)
> -
>  Optional properties:
>  
>- wlf,reset : GPIO specifier for the GPIO controlling /RESET
> -  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
>  
>- wlf,gpio-defaults : A list of GPIO configuration register values. Defines
>  for the appropriate values can found in . If
> @@ -67,21 +55,9 @@ Optional properties:
>  present, the number of values should be less than or equal to the
>  number of inputs, unspecified inputs will use the chip default.
>  
> -  - wlf,hpdet-channel : Headphone detection channel.
> -ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
> -ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
> -If this node is not mentioned or if the value is unknown, then
> -headphone detection mode is set to HPDETL.
> -
> -  - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified 
> if
> -they are being externally supplied. As covered in
> -Documentation/devicetree/bindings/regulator/regulator.txt
> -
> -Optional subnodes:
> -  - ldo1 : Initial data for the LDO1 regulator, as covered in
> -Documentation/devicetree/bindings/regulator/regulator.txt
> -  - micvdd : Initial data for the MICVDD regulator, as covered in
> -Documentation/devicetree/bindings/regulator/regulator.txt
> +Also see child specific device properties:
> +  Regulator - ../regulator/arizona-regulator.txt
> +  Extcon- ../extcon/extcon-arizona.txt
>  
>  Example:
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f353491..544c747 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11395,6 +11395,7 @@ S:Supported
>  F:   Documentation/hwmon/wm83??
>  F:   Documentation/devicetree/bindings/extcon/extcon-arizona.txt
>  F:   Documentation/devicetree/bindings/regulator/arizona-regulator.txt
> +F:   Documentation/devicetree/bindings/mfd/arizona.txt
>  F:   arch/arm/mach-s3c64xx/mach-crag6410*
>  F:   drivers/clk/clk-wm83*.c
>  F:   drivers/extcon/extcon-arizona.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] mmc: mediatek: Add tune support

[Sascha Hauer]

Hi,

On Tue, Oct 13, 2015 at 05:37:57PM +0800, Chaotian Jing wrote:
> @@ -1260,6 +1547,16 @@ static int msdc_drv_probe(struct platform_device *pdev)
>   goto host_free;
>   }
>  
> + host->src_clk_parent = clk_get_parent(host->src_clk);
> + host->hs400_src = devm_clk_get(>dev, "400mhz");
> + if (IS_ERR(host->hs400_src)) {
> + dev_dbg(>dev, "Cannot find 400mhz at dts!\n");
> + } else if (clk_set_parent(host->src_clk_parent, host->hs400_src) < 0) {
> + dev_err(host->dev, "Failed to set 400mhz source clock!\n");
> + ret = -EINVAL;
> + goto host_free;
> + }

This is a static setup. We have device tree bindings for doing this.
Please look for assigned-clocks and assigned-clock-parents. Doing stuff
like this in the driver almost certainly leads to problems because the
next SoC will have different requirements here.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>> * Franklin S Cooper Jr.  [151014 09:27]:
>>>
>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
 * Franklin S Cooper Jr.  [151014 07:37]:
> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
 Franklin,

 On 14/10/15 14:36, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Switch from dma_request_channel to allow passing dma channel
>> information from DT rather than hardcoding a value.
>>
>> Signed-off-by: Franklin S Cooper Jr 
> Acked-by: Roger Quadros 
>
>> ---
>>  drivers/mtd/nand/omap2.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index d0f2620..957c32f 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>> platform_device *pdev)
>>  dma_cap_zero(mask);
>>  dma_cap_set(DMA_SLAVE, mask);
>>  sig = OMAP24XX_DMA_GPMC;
>> -info->dma = dma_request_channel(mask, 
>> omap_dma_filter_fn, );
>> +info->dma = dma_request_slave_channel_compat(mask,
>> +omap_dma_filter_fn, , pdev->dev.parent, 
>> "rxtx");
>> +
 Just discovered that you are using the parent device node.

 How about moving the dma bindings to the nand node instead and using
 pdev->dev here?
>>> Roger,
>>>
>>> From what I can tell the interrupt number and the dma channel will 
>>> always be
>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>> combination of nands and nors. Since that is the case I think it just 
>>> makes
>>> sense to leave it in the gpmc parent node and define it once.
>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>> or only for NAND?
> The dma seems tied to the prefetch. From what I can tell the prefetch is 
> only
> used by nand.
>> Let's also get Tony's inputs on this.
> Sure.
 Hmm so what would keep other devices from using the prefetch
>>> Looking at the TRM any references to the prefetch are always with respect to
>>> NAND.
>>>
>>> I also see the below mentioned in the TRM.
>>> Pre-fetch and write posting engine associated with system DMA to get full 
>>> performance from NAND
>>> device with minimum impact on NOR/SRAM concurrent access.
>> OK up to you guys to figure out if it may be usable in a generic way then :)
> Ok I just got clarification from hw folks. DMA for GPMC can be used for any 
> of the
> various modes. But the prefetch is specific to NAND.

In that case the dma information must be in the GPMC node.

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

Re: [PATCH 09/25] scsi: hisi_sas: add phy SAS ADDR initialization

[Arnd Bergmann]

On Thursday 15 October 2015 11:36:53 zhangfei wrote:
> On 10/14/2015 11:18 PM, Arnd Bergmann wrote:
> > On Wednesday 14 October 2015 16:05:21 John Garry wrote:
> >>
> >> OK, we can look at adding the ability to read the SAS HBA address from a
> >> FW image or EFI variables.
> >>
> >
> > The easiest way is usually to have a DT property that gets updated
> > by the firmware.
> >
> 
> Yes
> In net subsystem, there is mac-address.
> 
> In dts, we set default mac-address, which will be modified by 
> boot-loader, if all 0 random address will be used.
> mac-address = [00 00 00 00 00 00];
> 
> In driver, mac-address can be get via of_get_mac_address.
> 
> Can we use the similar method here?

Good idea, I think this is the best way.

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

Re: [PATCH 03/25] scsi: hisi_sas: add initial bare driver

[Xinwei Kong]

On 2015/10/12 23:20, John Garry wrote:
> This patch adds the initial bare driver for the HiSilicon
> SAS HBA. The driver includes no HW interaction, but only
> the changes to build and load the driver module.
> 
> The HBA is a platform device.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/Kconfig  |  1 +
>  drivers/scsi/Makefile |  1 +
>  drivers/scsi/hisi_sas/Kconfig |  5 +++
>  drivers/scsi/hisi_sas/Makefile|  2 ++
>  drivers/scsi/hisi_sas/hisi_sas.h  | 24 +++
>  drivers/scsi/hisi_sas/hisi_sas_init.c | 58 
> +++
>  6 files changed, 91 insertions(+)
>  create mode 100644 drivers/scsi/hisi_sas/Kconfig
>  create mode 100644 drivers/scsi/hisi_sas/Makefile
>  create mode 100644 drivers/scsi/hisi_sas/hisi_sas.h
>  create mode 100644 drivers/scsi/hisi_sas/hisi_sas_init.c
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 95f7a76..5c345f9 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -1774,5 +1774,6 @@ source "drivers/scsi/pcmcia/Kconfig"
>  source "drivers/scsi/device_handler/Kconfig"
>  
>  source "drivers/scsi/osd/Kconfig"
> +source "drivers/scsi/hisi_sas/Kconfig"
>  
>  endmenu
> diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
> index 1a8c9b5..03c30de 100644
> --- a/drivers/scsi/Makefile
> +++ b/drivers/scsi/Makefile
> @@ -158,6 +158,7 @@ obj-$(CONFIG_CHR_DEV_SCH) += ch.o
>  obj-$(CONFIG_SCSI_ENCLOSURE) += ses.o
>  
>  obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
> +obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas/
>  
>  # This goes last, so that "real" scsi devices probe earlier
>  obj-$(CONFIG_SCSI_DEBUG) += scsi_debug.o
> diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
> new file mode 100644
> index 000..a7f47a2
> --- /dev/null
> +++ b/drivers/scsi/hisi_sas/Kconfig
> @@ -0,0 +1,5 @@
> +config SCSI_HISI_SAS
> + tristate "HiSilicon SAS"
> + select SCSI_SAS_LIBSAS
> + help
> + This driver supports HiSilicon's SAS HBA
> diff --git a/drivers/scsi/hisi_sas/Makefile b/drivers/scsi/hisi_sas/Makefile
> new file mode 100644
> index 000..63c3c4d
> --- /dev/null
> +++ b/drivers/scsi/hisi_sas/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas.o
> +hisi_sas-y+= hisi_sas_init.o
> diff --git a/drivers/scsi/hisi_sas/hisi_sas.h 
> b/drivers/scsi/hisi_sas/hisi_sas.h
> new file mode 100644
> index 000..50204a2
> --- /dev/null
> +++ b/drivers/scsi/hisi_sas/hisi_sas.h
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Copyright (c) 2015 Hisilicon Limited.
> + *
> + * This program 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.
> + *
> + */
> +
> +#ifndef _HISI_SAS_H_
> +#define _HISI_SAS_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
why place some "include" head in .h file rather than .c file?
> +#define DRV_NAME "hisi_sas"
> +#define DRV_VERSION "v1.0"
> +
> +#endif
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_init.c 
> b/drivers/scsi/hisi_sas/hisi_sas_init.c
> new file mode 100644
> index 000..dd83430
> --- /dev/null
> +++ b/drivers/scsi/hisi_sas/hisi_sas_init.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Copyright (c) 2015 Hisilicon Limited.
> + *
> + * This program 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.
> + *
> + */
> +
> +#include "hisi_sas.h"
> +
> +static const struct of_device_id sas_of_match[] = {
> + { .compatible = "hisilicon,sas-controller-v1",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, sas_of_match);
> +static int hisi_sas_probe(struct platform_device *pdev)
> +{
> +
> + return 0;
> +}
> +
> +static int hisi_sas_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static struct platform_driver hisi_sas_driver = {
> + .probe = hisi_sas_probe,
> + .remove = hisi_sas_remove,
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = sas_of_match,
> + },
> +};
> +
> +static __init int hisi_sas_init(void)
> +{
> + pr_info("hisi_sas: driver version %s\n", DRV_VERSION);
> +
> + return platform_driver_register(_sas_driver);
> +}
> +
> +static __exit void hisi_sas_exit(void)
> +{
> + platform_driver_unregister(_sas_driver);
> +}
> +
> +module_init(hisi_sas_init);
> +module_exit(hisi_sas_exit);
> +
> +MODULE_VERSION(DRV_VERSION);
> +MODULE_LICENSE("GPL");
V2
> +MODULE_AUTHOR("John Garry ");
> +MODULE_DESCRIPTION("HISILICON SAS controller driver");
> +MODULE_ALIAS("platform:" DRV_NAME);
> 

--
To 

[PATCH 1/3] ARM: dts: uniphier: change the external bus address mapping

[Masahiro Yamada]

In UniPhier SoCs before ProXstream2 and PH1-LD6b, two address spaces
 0x - 0x0fff
 0x4000 - 0x4fff
are both mapped to the external bus (also called system bus),
so either was OK.

In the newest two SoCs, the former (0x - 0x0fff) is
assigned for the serial NOR interface.

For the consistency, use the latter for all the SoCs.

Also, fix the range properties to reflect the real address mapping,
where the support card is located at the offset address 0x01f0
of CS1 of the external bus.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts  | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 5 ++---
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index bfd3bb8..e9722a5 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -74,12 +74,11 @@
 };
 
  {
-   ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+   ranges = <1 0x 0x4200 0x0200>;
 };
 
 _card {
-   ranges = <0x 1 0x03f0 0x0010>;
+   ranges = <0x 1 0x01f0 0x0010>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 3a6f1f6..1a402ed 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -76,12 +76,11 @@
 };
 
  {
-   ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+   ranges = <1 0x 0x4200 0x0200>;
 };
 
 _card {
-   ranges = <0x 1 0x03f0 0x0010>;
+   ranges = <0x 1 0x01f0 0x0010>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 69a5b7d..47e2edb 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -76,12 +76,11 @@
 };
 
  {
-   ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+   ranges = <1 0x 0x4200 0x0200>;
 };
 
 _card {
-   ranges = <0x 1 0x03f0 0x0010>;
+   ranges = <0x 1 0x01f0 0x0010>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index 1a440f8..adcbbc6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -75,12 +75,11 @@
 };
 
  {
-   ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+   ranges = <1 0x 0x4200 0x0200>;
 };
 
 _card {
-   ranges = <0x 1 0x03f0 0x0010>;
+   ranges = <0x 1 0x01f0 0x0010>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index 955d417..bcf2e7c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -74,12 +74,11 @@
 };
 
  {
-   ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+   ranges = <1 0x 0x4200 0x0200>;
 };
 
 _card {
-   ranges = <0x 1 0x03f0 0x0010>;
+   ranges = <0x 1 0x01f0 0x0010>;
 };
 
  {
-- 
1.9.1

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

Re: [PATCH 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Peter Ujfalusi]

Tony,

On 10/12/2015 11:57 PM, Tony Lindgren wrote:
> * Tony Lindgren  [150914 09:32]:
>> * Peter Ujfalusi  [150914 01:54]:
>>> Hi Tony,
>>>
>>> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
 Hi,

 this series will enable analog audio (via onboard aic310x codec) for 
 dra7-evm,
 dra72-evm and am57xx-beagle-x15 boards.
 In these board McASP3 is connected to the codec and for the McASP3 we 
 needed to
 have the DMA crossbar in place since the request lines are not mapped by
 default.
>>>
>>> Did you had a chance to look at this series?
>>
>> Looks OK to me, will look at it more once we have the fixes merged.
>>
>> Paul may have comments on the hwmod chage, looks like you forgot
>> to Cc him on it. Can you please resend that one with Paul in Cc?
> 
> Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
> can pick up the hwmod change then after reviewing it.

Thanks for taking the DTS patches, however if Paul agrees with the way I think 
we can handle the McASP in DRA7xx then the patch which adds the mcasp3 node to 
dra7.dtsi needs to be replaced by:

>From b6733f9ca96a997fab3d0455783e875dd9ae032b Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi 
Date: Tue, 24 Feb 2015 15:12:59 +0200
Subject: [PATCH v2 03/12] ARM: DTS: dra7: Add McASP3 node

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8fedddc35999..cde0a3cbf262 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1404,6 +1404,21 @@
status = "disabled";
};
 
+   mcasp3: mcasp@48468000 {
+   compatible = "ti,dra7-mcasp-audio";
+   ti,hwmods = "mcasp3";
+   reg = <0x48468000 0x2000>;
+   reg-names = "mpu";
+   interrupts = ,
+;
+   interrupt-names = "tx", "rx";
+   dmas = <_xbar 133>, <_xbar 132>;
+   dma-names = "tx", "rx";
+   clocks = <_aux_gfclk_mux>, <_ahclkx_mux>;
+   clock-names = "fck", "ahclkx";
+   status = "disabled";
+   };
+
crossbar_mpu: crossbar@4a002a48 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
-- 
2.6.1




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

Re: [PATCH 1/5] dt-bindings: MIPS: Document xilfpga bindings and boot style

[James Hogan]

Hi Zubair,

On Wed, Oct 14, 2015 at 01:51:53PM +0100, Zubair Lutfullah Kakakhel wrote:
> Xilfpga boots only with device-tree. Document the required properties
> and the unique boot style
> 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> ---
>  .../devicetree/bindings/mips/img/xilfpga.txt   | 76 
> ++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mips/img/xilfpga.txt
> 
> diff --git a/Documentation/devicetree/bindings/mips/img/xilfpga.txt 
> b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
> new file mode 100644
> index 000..1e7084c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
> @@ -0,0 +1,76 @@
> +Imagination University Program MIPSFpga
> +===
> +
> +Under the Imagination University Program, a microAptiv UP core has been 
> released for academic usage.

Documentation files should still be wrapped to 80 columns.

> +
> +As we are dealing with a mips core instantiated on an FPGA, specifications 
> are fluid and can be varied in RTL.
> +
> +This binding document is provided as baseline guidance for the example 
> project provided by IMG.
> +
> +The example project runs on the Nexys4DDR board by Digilent powered by the 
> ARTIX-7 FPGA by Xilinx.
> +
> +Relevant details about the example project and the Nexys4DDR board:
> +
> +- microAptiv UP core m14Kc
> +- 50MHz clock speed
> +- 128Mbyte DDR RAM   at 0x_
> +- 8Kbyte RAM at 0x1000_
> +- axi_intc   at 0x1020_
> +- axi_uart16550  at 0x1040_
> +- axi_gpio   at 0x1060_
> +- axi_i2cat 0x10A0_
> +- custom_gpioat 0x10C0_
> +- axi_ethernetlite   at 0x10E0_
> +- 8Kbyte BootRAM at 0x1FC0_
> +
> +Required properties:
> +
> + - compatible: Must include "img,xilfpga".

Is that specific enough to describe the system you're referring to
unambiguously?

> +
> +CPU nodes:
> +--
> +A "cpus" node is required.  Required properties:
> + - #address-cells: Must be 1.
> + - #size-cells: Must be 0.
> +A CPU sub-node is also required for at least CPU 0. Required properties:
> + - device_type: Must be "cpu".
> + - compatible: Must be "mips,m14Kc".
> + - reg: Must be <0>.
> + - clocks: Must include the CPU clock.  See ../../clock/clock-bindings.txt 
> for
> +   details on clock bindings.
> + - ext clock handle for fixed-clock received by MIPS core.

that last bullet would appear to be a description of required clocks,
rather than a required property of the cpu node. Perhaps it should be in
the same paragraph as clocks property description.

> +Example:

your example doesn't have the required compatible string.

> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "mips,m14Kc";
> + reg = <0>;
> + clocks  = <>;
> + };
> + };
> +
> + ext: ext {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <5000>;
> + };
> +
> +Boot protocol:
> +--
> +
> +The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_. This is for easy 
> reprogrammibility via JTAG.
> +
> +The BootRAM inializes the cache and the axi_uart peripheral.
> +
> +DDR initialiation is already handled by a HW IP block.
> +
> +When the example project bitstream is loaded, the cpu_reset button needs to 
> be pressed.
> +
> +The bootram initializes the cache and axi_uart. Then outputs MIPSFPGA\n\r on 
> the serial port
> +on the Nexys4DDR board.
> +
> +At this point, the board is ready to load the Linux kernel vmlinux file via 
> JTAG.

Maybe worth clarifying whether register state should be set to anything
in particular, such as setting argument registers to zero so that you
could use them for passing command line or device tree in future, e.g.
if somebody ported u-boot to it (maybe ensure its compatible with the
UHI boot specs).

Cheers
James


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH 2/6] mfd: axp20x: Split the driver into core and i2c bits

[Chen-Yu Tsai]

On Thu, Oct 15, 2015 at 6:37 AM, Julian Calaby  wrote:
> Hi Chen-Yu,
>
> On Thu, Oct 15, 2015 at 3:32 AM, Chen-Yu Tsai  wrote:
>> The axp20x driver assumes the device is i2c based. This is not the
>> case with later models, which use a proprietary 2 wire serial bus
>> called "Reduced Serial Bus".
>>
>> This patch follows the example of mfd/wm831x and splits it into
>> an interface independet core, and an i2c specific glue layer.
>>
>> The old MFD_AXP20X Kconfig symbol is kept until sub-device drivers
>> and defconfigs have migrated to the new MFD_AXP20X_CORE symbol.
>>
>> Included but unused header files are removed as well.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/mfd/Kconfig |  18 -
>>  drivers/mfd/Makefile|   3 +-
>>  drivers/mfd/{axp20x.c => axp20x-core.c} | 105 +++---
>>  drivers/mfd/axp20x-i2c.c| 127 
>> 
>>  include/linux/mfd/axp20x.h  |  33 -
>>  5 files changed, 186 insertions(+), 100 deletions(-)
>>  rename drivers/mfd/{axp20x.c => axp20x-core.c} (87%)
>>  create mode 100644 drivers/mfd/axp20x-i2c.c
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 99d63675f073..9ba3feb3f2fc 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -79,15 +79,25 @@ config MFD_BCM590XX
>> help
>>   Support for the BCM590xx PMUs from Broadcom
>>
>> +# Keep the old symbol until subdevice driver dependencies and defconfigs
>> +# have been updated.
>>  config MFD_AXP20X
>> -   bool "X-Powers AXP20X"
>> +   bool "X-Powers AXP series PMICs"
>> +   select MFD_AXP20X_I2C
>
> Unless something has changed in KConfig, (and my knowledge on this is
> likely to be outdated) I don't believe this will work as I don't think
> selects don't get propagated like you expect. Have you checked that
> all possible configuration options survive make oldconfig and build
> without warnings?

Yeah this totally did not work out like I expected.

> Also, unless there's some compelling reason not to, it's probably a
> good idea to update the dependent drivers and defconfigs now. (or make
> this change in a gentler manner.)

What I wanted was to keep the original symbol for a release cycle or
more, giving me time to update the related entries across the kernel.
After the changes are in, we could remove the old one.

The other way would be to change MFD_AXP20X to a hidden symbol, and
let the 2 new ones select that. Then we'd just update all the
defconfigs.

I'll rework this and add defconfig updates.

Thanks
ChenYu

>> +
>> +config MFD_AXP20X_CORE
>> +   bool
>> select MFD_CORE
>> -   select REGMAP_I2C
>> select REGMAP_IRQ
>> +
>> +config MFD_AXP20X_I2C
>> +   bool "X-Powers AXP series I2C PMICs"
>> +   select MFD_AXP20X_CORE
>> +   select REGMAP_I2C
>> depends on I2C=y
>> help
>> - If you say Y here you get support for the X-Powers AXP202, AXP209 
>> and
>> - AXP288 power management IC (PMIC).
>> + If you say Y here you get support for the X-Powers AXP series I2C
>> + based power management ICs (PMICs).
>>   This driver include only the core APIs. You have to select 
>> individual
>>   components like regulators or the PEK (Power Enable Key) under the
>>   corresponding menus.
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.cal...@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/25] scsi: hisi_sas: add initial bare driver

[John Garry]

On 15/10/2015 09:49, Xinwei Kong wrote:



On 2015/10/12 23:20, John Garry wrote:

This patch adds the initial bare driver for the HiSilicon
SAS HBA. The driver includes no HW interaction, but only
the changes to build and load the driver module.

The HBA is a platform device.

Signed-off-by: John Garry 
---
  drivers/scsi/Kconfig  |  1 +
  drivers/scsi/Makefile |  1 +
  drivers/scsi/hisi_sas/Kconfig |  5 +++
  drivers/scsi/hisi_sas/Makefile|  2 ++
  drivers/scsi/hisi_sas/hisi_sas.h  | 24 +++
  drivers/scsi/hisi_sas/hisi_sas_init.c | 58 +++
  6 files changed, 91 insertions(+)
  create mode 100644 drivers/scsi/hisi_sas/Kconfig
  create mode 100644 drivers/scsi/hisi_sas/Makefile
  create mode 100644 drivers/scsi/hisi_sas/hisi_sas.h
  create mode 100644 drivers/scsi/hisi_sas/hisi_sas_init.c

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 95f7a76..5c345f9 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1774,5 +1774,6 @@ source "drivers/scsi/pcmcia/Kconfig"
  source "drivers/scsi/device_handler/Kconfig"

  source "drivers/scsi/osd/Kconfig"
+source "drivers/scsi/hisi_sas/Kconfig"

  endmenu
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 1a8c9b5..03c30de 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_CHR_DEV_SCH)   += ch.o
  obj-$(CONFIG_SCSI_ENCLOSURE)  += ses.o

  obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
+obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas/

  # This goes last, so that "real" scsi devices probe earlier
  obj-$(CONFIG_SCSI_DEBUG)  += scsi_debug.o
diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
new file mode 100644
index 000..a7f47a2
--- /dev/null
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -0,0 +1,5 @@
+config SCSI_HISI_SAS
+   tristate "HiSilicon SAS"
+   select SCSI_SAS_LIBSAS
+   help
+   This driver supports HiSilicon's SAS HBA
diff --git a/drivers/scsi/hisi_sas/Makefile b/drivers/scsi/hisi_sas/Makefile
new file mode 100644
index 000..63c3c4d
--- /dev/null
+++ b/drivers/scsi/hisi_sas/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas.o
+hisi_sas-y+= hisi_sas_init.o
diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
new file mode 100644
index 000..50204a2
--- /dev/null
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program 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.
+ *
+ */
+
+#ifndef _HISI_SAS_H_
+#define _HISI_SAS_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+

why place some "include" head in .h file rather than .c file?

This is private header within the module, which:
- makes the code more concise
- relocate functions within c files is cleaner
- easier to change the kernel APIs we use in the module


+#define DRV_NAME "hisi_sas"
+#define DRV_VERSION "v1.0"
+
+#endif
diff --git a/drivers/scsi/hisi_sas/hisi_sas_init.c 
b/drivers/scsi/hisi_sas/hisi_sas_init.c
new file mode 100644
index 000..dd83430
--- /dev/null
+++ b/drivers/scsi/hisi_sas/hisi_sas_init.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program 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.
+ *
+ */
+
+#include "hisi_sas.h"
+
+static const struct of_device_id sas_of_match[] = {
+   { .compatible = "hisilicon,sas-controller-v1",},
+   {},
+};
+MODULE_DEVICE_TABLE(of, sas_of_match);
+static int hisi_sas_probe(struct platform_device *pdev)
+{
+
+   return 0;
+}
+
+static int hisi_sas_remove(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static struct platform_driver hisi_sas_driver = {
+   .probe = hisi_sas_probe,
+   .remove = hisi_sas_remove,
+   .driver = {
+   .name = DRV_NAME,
+   .of_match_table = sas_of_match,
+   },
+};
+
+static __init int hisi_sas_init(void)
+{
+   pr_info("hisi_sas: driver version %s\n", DRV_VERSION);
+
+   return platform_driver_register(_sas_driver);
+}
+
+static __exit void hisi_sas_exit(void)
+{
+   platform_driver_unregister(_sas_driver);
+}
+
+module_init(hisi_sas_init);
+module_exit(hisi_sas_exit);
+
+MODULE_VERSION(DRV_VERSION);
+MODULE_LICENSE("GPL");

V2

Can add. We do say in the header that it is v2.


+MODULE_AUTHOR("John Garry ");
+MODULE_DESCRIPTION("HISILICON SAS controller driver");
+MODULE_ALIAS("platform:" 

Re: [PATCH v6 0/5] Add DT support for netxbig LEDs

[Jacek Anaszewski]

Hi Gregory,

On 10/15/2015 09:16 AM, Gregory CLEMENT wrote:

Hi Jacek,

  On ven., oct. 09 2015, Jacek Anaszewski  wrote:


On 09/26/2015 11:02 PM, Simon Guinot wrote:

Hello,


[..]


Simon Guinot (5):
leds: netxbig: add device tree binding
ARM: Kirkwood: add LED DT entries for netxbig boards
ARM: mvebu: remove static LED setup for netxbig boards
leds: netxbig: convert to use the devm_ functions
leds: netxbig: set led_classdev max_brightness

   .../devicetree/bindings/gpio/netxbig-gpio-ext.txt  |  22 ++
   .../devicetree/bindings/leds/leds-netxbig.txt  |  92 ++
   arch/arm/boot/dts/kirkwood-net5big.dts |  60 
   arch/arm/boot/dts/kirkwood-netxbig.dtsi|  80 +
   arch/arm/mach-mvebu/Kconfig|   7 -
   arch/arm/mach-mvebu/Makefile   |   1 -
   arch/arm/mach-mvebu/board.h|  21 --
   arch/arm/mach-mvebu/kirkwood.c |   4 -
   arch/arm/mach-mvebu/netxbig.c  | 191 
   drivers/leds/leds-netxbig.c| 336 
-
   include/dt-bindings/leds/leds-netxbig.h|  18 ++
   .../linux/platform_data/leds-kirkwood-netxbig.h|   1 +
   12 files changed, 531 insertions(+), 302 deletions(-)
   create mode 100644 
Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
   create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
   delete mode 100644 arch/arm/mach-mvebu/board.h
   delete mode 100644 arch/arm/mach-mvebu/netxbig.c
   create mode 100644 include/dt-bindings/leds/leds-netxbig.h



Since no comment regarding DT bindings has appeared for a long time,
I decided to merge the patch set without DT maintainer's ack, thanks.


it is a good news that this series will be finally merged. However did
you also take the patches "ARM: Kirkwood: add LED DT entries for netxbig
boards" and "ARM: mvebu: remove static LED setup for netxbig boards" ?


Yes, I did:

https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-leds.git/log/?h=for-next

They should appear in the next issue of linux-next.

--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] MIPS: Add xilfpga defconfig

[James Hogan]

On Wed, Oct 14, 2015 at 01:51:57PM +0100, Zubair Lutfullah Kakakhel wrote:
> Signed-off-by: Zubair Lutfullah Kakakhel 
> ---
>  arch/mips/configs/xilfpga_defconfig | 59 
> +
>  1 file changed, 59 insertions(+)
>  create mode 100644 arch/mips/configs/xilfpga_defconfig
> 
> diff --git a/arch/mips/configs/xilfpga_defconfig 
> b/arch/mips/configs/xilfpga_defconfig
> new file mode 100644
> index 000..94bb9b8
> --- /dev/null
> +++ b/arch/mips/configs/xilfpga_defconfig
> @@ -0,0 +1,59 @@
> +CONFIG_MACH_XILFPGA=y
> +# CONFIG_COMPACTION is not set
> +# CONFIG_LOCALVERSION_AUTO is not set
> +# CONFIG_CROSS_MEMORY_ATTACH is not set
> +# CONFIG_USELIB is not set
> +# CONFIG_SHMEM is not set
> +# CONFIG_AIO is not set
> +# CONFIG_ADVISE_SYSCALLS is not set

Did you disable these intentionally? Its a kernel tinification option
that is rarely used in defconfigs.

> +CONFIG_EMBEDDED=y
> +# CONFIG_VM_EVENT_COUNTERS is not set
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLAB=y
> +# CONFIG_BLOCK is not set
> +# CONFIG_SUSPEND is not set
> +# CONFIG_UEVENT_HELPER is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_STANDALONE is not set
> +# CONFIG_PREVENT_FIRMWARE_BUILD is not set
> +# CONFIG_FW_LOADER is not set
> +# CONFIG_ALLOW_DEV_COREDUMP is not set
> +# CONFIG_INPUT_MOUSEDEV is not set
> +# CONFIG_INPUT_KEYBOARD is not set
> +# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_SERIO is not set
> +CONFIG_VT_HW_CONSOLE_BINDING=y
> +# CONFIG_UNIX98_PTYS is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> +CONFIG_SERIAL_8250_NR_UARTS=1
> +CONFIG_SERIAL_8250_RUNTIME_UARTS=1
> +CONFIG_SERIAL_OF_PLATFORM=y
> +# CONFIG_HW_RANDOM is not set
> +CONFIG_GPIO_SYSFS=y
> +CONFIG_GPIO_XILINX=y
> +# CONFIG_HWMON is not set
> +# CONFIG_USB_SUPPORT is not set
> +# CONFIG_MIPS_PLATFORM_DEVICES is not set
> +# CONFIG_IOMMU_SUPPORT is not set
> +# CONFIG_FILE_LOCKING is not set

Likewise, intentional? Its another tinification option that isn't all
that commonly used in defconfigs.

> +# CONFIG_DNOTIFY is not set
> +# CONFIG_INOTIFY_USER is not set

Likewise, intentional? I don't think inotify is deprecated in favour of
anything else yet (it appears to superscede dnotify).

> +# CONFIG_PROC_SYSCTL is not set

Likewise.

> +# CONFIG_PROC_PAGE_MONITOR is not set
> +# CONFIG_MISC_FILESYSTEMS is not set
> +# CONFIG_ENABLE_WARN_DEPRECATED is not set
> +# CONFIG_ENABLE_MUST_CHECK is not set

Particular reason to disable these two compile time warnings?

> +CONFIG_PANIC_ON_OOPS=y
> +# CONFIG_SCHED_DEBUG is not set
> +CONFIG_DEBUG_LOCK_ALLOC=y

Did you mean to leave this turned on?

> +# CONFIG_FTRACE is not set
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE="console=ttyS0,115200 clk_ignore_unused 
> earlyprintk=serial,ttyS0,115200"

I believe you can specify an earlyprintk address on command line. Would
it be preferable to do that rather than hard coding the address in the
platform code?

Cheers
James

> +CONFIG_CRYPTO_MD5=y
> +CONFIG_CRYPTO_SHA1=y
> +CONFIG_CRYPTO_DES=y
> +CONFIG_CRYPTO_DEFLATE=y
> +CONFIG_CRC16=y
> +CONFIG_LIBCRC32C=y
> -- 
> 1.9.1
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

[James Hogan]

Hi Harvey,

On Tue, Oct 06, 2015 at 05:27:17PM +0100, Harvey Hunt wrote:
> From: Alex Smith 
> 
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
> 
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
> 
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
> 
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
> 
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";

Isn't the NAND a micron part? This doesn't seem right. Is the device
driver and binding already accepted upstream with that compatible
string?

Cheers
James

> + reg = <1 0 0x100>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
> +
> + ingenic,bch-controller = <>;
> + ingenic,ecc-size = <1024>;
> + ingenic,ecc-strength = <24>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + partition@0 {
> + label = "u-boot-spl";
> + reg = <0x0 0x0 0x0 0x80>;
> + };
> +
> + partition@0x80 {
> + label = "u-boot";
> + reg = <0x0 0x80 0x0 0x20>;
> + };
> +
> + partition@0xa0 {
> + label = "u-boot-env";
> + reg = <0x0 0xa0 0x0 0x20>;
> + };
> +
> + partition@0xc0 {
> + label = "boot";
> + reg = <0x0 0xc0 0x0 0x400>;
> + };
> +
> + partition@0x8c0 {
> + label = "system";
> + reg = <0x0 0x4c0 0x1 0xfb40>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index 65389f6..b868b42 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -108,4 +108,30 @@
>  
>   status = "disabled";
>   };
> +
> + nemc: nemc@1341 {
> + compatible = "ingenic,jz4780-nemc";
> + reg = <0x1341 0x1>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0x1b00 0x100
> +   2 0 0x1a00 0x100
> +   3 0 0x1900 0x100
> +   4 0 0x1800 0x100
> +   5 0 0x1700 0x100
> +   6 0 0x1600 0x100>;
> +
> + clocks = < JZ4780_CLK_NEMC>;
> +
> + status = "disabled";
> + };
> +
> + bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = < JZ4780_CLK_BCH>;
> +
> + status = "disabled";
> + };
>  };
> -- 
> 2.6.0
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH 4/5] MIPS: xilfpga: Add mipsfpga platform code

[James Hogan]

On Wed, Oct 14, 2015 at 01:51:56PM +0100, Zubair Lutfullah Kakakhel wrote:
> The xilfpga platform will be DT only.
> 
> Add required platform code. DT files have already been added separately

Please wrap to 72 characters (keeps it looking pretty in git-log
output), and maybe add a full stop.

> 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> ---
>  arch/mips/Kbuild.platforms|  1 +
>  arch/mips/Kconfig | 25 ++
>  arch/mips/include/asm/mach-xilfpga/gpio.h | 19 +++
>  arch/mips/include/asm/mach-xilfpga/irq.h  | 18 ++
>  arch/mips/xilfpga/Kconfig |  9 +
>  arch/mips/xilfpga/Makefile|  7 
>  arch/mips/xilfpga/Platform|  3 ++
>  arch/mips/xilfpga/init.c  | 57 
> +++
>  arch/mips/xilfpga/intc.c  | 26 ++
>  arch/mips/xilfpga/time.c  | 41 ++
>  10 files changed, 206 insertions(+)
>  create mode 100644 arch/mips/include/asm/mach-xilfpga/gpio.h
>  create mode 100644 arch/mips/include/asm/mach-xilfpga/irq.h
>  create mode 100644 arch/mips/xilfpga/Kconfig
>  create mode 100644 arch/mips/xilfpga/Makefile
>  create mode 100644 arch/mips/xilfpga/Platform
>  create mode 100644 arch/mips/xilfpga/init.c
>  create mode 100644 arch/mips/xilfpga/intc.c
>  create mode 100644 arch/mips/xilfpga/time.c
> 
> diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> index a424e46..a96c81d 100644
> --- a/arch/mips/Kbuild.platforms
> +++ b/arch/mips/Kbuild.platforms
> @@ -33,6 +33,7 @@ platforms += sibyte
>  platforms += sni
>  platforms += txx9
>  platforms += vr41xx
> +platforms += xilfpga
>  
>  # include the platform specific files
>  include $(patsubst %, $(srctree)/arch/mips/%/Platform, $(platforms))
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index e3aa5b0..66c1a7e 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -401,6 +401,30 @@ config MACH_PISTACHIO
>   help
> This enables support for the IMG Pistachio SoC platform.
>  
> +config MACH_XILFPGA
> + bool "MIPSFPGA Xilinx based boards"
> + select ARCH_REQUIRE_GPIOLIB
> + select BOOT_ELF32
> + select BOOT_RAW
> + select BUILTIN_DTB
> + select CEVT_R4K
> + select COMMON_CLK
> + select CSRC_R4K
> + select IRQ_MIPS_CPU
> + select LIBFDT
> + select MIPS_CPU_SCACHE
> + select SERIAL_8250
> + select SERIAL_8250_CONSOLE

Is it really necessary to select SERIAL_8250[_CONSOLE]? Its something
that I think belongs in the defconfig rather than as a strict
requirement to enable the platform.

> + select SYS_HAS_EARLY_PRINTK
> + select SYS_HAS_CPU_MIPS32_R2
> + select SYS_SUPPORTS_32BIT_KERNEL
> + select SYS_SUPPORTS_LITTLE_ENDIAN
> + select SYS_SUPPORTS_ZBOOT_UART16550
> + select USE_OF
> + select USE_GENERIC_EARLY_PRINTK_8250
> + help
> +   This enables support for the Xilinx

Is some description missing here?

> +
>  config MIPS_MALTA
>   bool "MIPS Malta board"
>   select ARCH_MAY_HAVE_PC_FDC
> @@ -964,6 +988,7 @@ source "arch/mips/loongson32/Kconfig"
>  source "arch/mips/loongson64/Kconfig"
>  source "arch/mips/netlogic/Kconfig"
>  source "arch/mips/paravirt/Kconfig"
> +source "arch/mips/xilfpga/Kconfig"
>  
>  endmenu
>  
> diff --git a/arch/mips/include/asm/mach-xilfpga/gpio.h 
> b/arch/mips/include/asm/mach-xilfpga/gpio.h
> new file mode 100644
> index 000..26778fc
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-xilfpga/gpio.h
> @@ -0,0 +1,19 @@
> +/*
> + * Copyright (C) 2015 Imagination Technologies
> + * Author: Zubair Lutfullah Kakakhel 
> + *
> + * This program 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.
> + */
> +
> +#ifndef __ASM_MACH_XILFPGA_GPIO_H
> +#define __ASM_MACH_XILFPGA_GPIO_H
> +
> +#include 
> +
> +#define gpio_get_value __gpio_get_value
> +#define gpio_set_value __gpio_set_value
> +
> +#endif /* __ASM_MACH_XILFPGA_GPIO_H */
> diff --git a/arch/mips/include/asm/mach-xilfpga/irq.h 
> b/arch/mips/include/asm/mach-xilfpga/irq.h
> new file mode 100644
> index 000..0132a5b9
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-xilfpga/irq.h
> @@ -0,0 +1,18 @@
> +/*
> + * Copyright (C) 2015 Imagination Technologies
> + * Author: Zubair Lutfullah Kakakhel 
> + *
> + * This program 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.
> + */
> +
> +#ifndef __MIPS_ASM_MACH_XILFPGA_IRQ_H__
> +#define 

Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Zhou Wang]

On 2015/10/15 5:56, Arnd Bergmann wrote:
> On Wednesday 14 October 2015 17:44:11 Zhou Wang wrote:
>> On 2015/10/14 17:06, Arnd Bergmann wrote:
>>> On Wednesday 14 October 2015 16:59:03 Zhou Wang wrote:

 Hi Arnd,

 In Hip05 PCIe host, it uses GITS_TRANSLATER's address to get TLP package
 which contains MSI address and MSI data, and then combine BDF and MSI data
 to a 32 bit data which will be writen to GITS_TRANSLATER register of ITS.

 I think maybe this is a defect of our PCIe controller.
>>>
>>> I'd consider it a bug in the firmware if this is not set up correctly
>>> before boot.
>>>
> I don't think what you do here is safe because the 'reg' property
> of the MSI controller might point to the address that is used for
> the message directly.

 I see your point, however we must get address of GITS_TRANSLATER and
 set it to PCIe host. How about adding necessary comments here?
>>>
>>> This seems to just be static setup that should be done before Linux
>>> is even loaded. Any reason you can't do it that way?
>>>
>>
>> There are some ITSs in Hip05-D02 platform, in fact, we can use any of them
>> as a msi-controller,  which we can configure in dts. I am afraid that
>> hard-setting the value in BIOS would lead to restrictions in terms of 
>> flexibility,
>> as with the current implementation the same BIOS-driver can fit different
>> DTS structures.
> 
> The dtb generally should be expected to match whatever the firmware sets up,
> so if there is one reasonable setting here, I see no problem with hardcoding
> it that way. In particular on server systems, we usually expect the firmware
> to configure almost everything in advance and just tell us how it is
> configured, while on embedded systems we can't trust the bootload and
> usually set it all up in the kernel from scratch.
>

I see your point. Actually in order to support platforms without PCIe 
configuration
support BIOS we planned to have a further commit once the driver was upstreamed,
where we check if the link is already up, if not we would configure it in the 
kernel,
otherwise we would return silently.

Now about this patchset we can remove GITS_TRANSLATER address setting and do 
this
in BIOS together with link-up setup; then in the next commit for supporting 
platforms
without PCIe setup in UEFI, we can add this part back where we first check
if the link is already up (we can assume that if BIOS has configured link-up,
it has also setup the msi-parent address), if the link is up we skip reading
msi-parent address.

> What would be a reason to pick one ITS over another?

In fact, we set PCIe host and ITS binding in dts. I mean that PCIe host can
bind to any ITS nodes in system.

> 
> On a related note, don't you also need to describe in DT how PCI B/D/F
> function numbers get turned into addresses in the ITS? Does that also
> require configuration in the driver? I see this code here:

We don't need to describe this. we need only describe the relationship between
PCIe host and ITS, PCIe host will service PCIe devices which are connected to 
it.

> 
> 
> +   hisi_pcie_apb_writel(pcie, PCIE_MSI_ASID_ENABLE | PCIE_MSI_ASID_VALUE,
> +PCIE_SLV_MSI_ASID);
> +   hisi_pcie_apb_writel(pcie, PCIE_MSI_TRANS_ENABLE, PCIE_MSI_TRANS_REG);
> +   hisi_pcie_change_apb_mode(pcie, PCIE_SLV_DBI_MODE);
>

This code is to enable MSI support in PCIe host.

> plus all of hisi_pcie_config_context(). This looks like it will change
> the way the MSI is interpreted. This also seems like something that
> could be done in the firmware in advance, and just get reported in DT.

I think all hisi_pcie_config_context can be move to BIOS for this patchset,
however in order to support other BIOSs which have no PCIe setup we would plan
a future commit adding this back and working as explained above.

Thanks,
Zhou

> 
>   Arnd
> 
> .
> 


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

Re: [PATCH 1/3] extcon: arizona: Add extcon specific device tree binding document

[Chanwoo Choi]

Hi Charles,

On 2015년 10월 14일 23:12, Charles Keepax wrote:
> Signed-off-by: Charles Keepax 
> ---
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |   15 +++
>  MAINTAINERS|1 +
>  2 files changed, 16 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> new file mode 100644
> index 000..e1705fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -0,0 +1,15 @@
> +Cirrus Logic Arizona class audio SoCs
> +
> +These devices are audio SoCs with extensive digital capabilities and a range
> +of analogue I/O.
> +
> +This document lists Extcon specific bindings, see the primary binding 
> document:
> +  ../mfd/arizona.txt
> +
> +Optional properties:
> +
> +  - wlf,hpdet-channel : Headphone detection channel.
> +ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
> +ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
> +If this node is not mentioned or if the value is unknown, then
> +headphone detection mode is set to HPDETL.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9f6685f..08c804a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11393,6 +11393,7 @@ T:git 
> https://github.com/CirrusLogic/linux-drivers.git
>  W:   https://github.com/CirrusLogic/linux-drivers/wiki
>  S:   Supported
>  F:   Documentation/hwmon/wm83??
> +F:   Documentation/devicetree/bindings/extcon/extcon-arizona.txt
>  F:   arch/arm/mach-s3c64xx/mach-crag6410*
>  F:   drivers/clk/clk-wm83*.c
>  F:   drivers/extcon/extcon-arizona.c
> 

You should add the description of patch.

If you add the description, looks good to me and you can add my acked tag.
Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: uniphier: add ProXstream2 Vodka board support

[Masahiro Yamada]

Initial version of DTS for ProXstream2 Vodka board.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/Makefile   |  3 +-
 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 79 
 2 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..9232018 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -672,7 +672,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-ld6b-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
-   uniphier-ph1-sld8-ref.dtb 
+   uniphier-ph1-sld8-ref.dtb \
+   uniphier-proxstream2-vodka.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts 
b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
new file mode 100644
index 000..27691f9
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Vodka Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL 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 file 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 file 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/ "uniphier-proxstream2.dtsi"
+
+/ {
+   model = "UniPhier ProXstream2 Vodka Board";
+   compatible = "socionext,proxstream2-vodka", "socionext,proxstream2";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   i2c0 = 
+   i2c4 = 
+   i2c5 = 
+   i2c6 = 
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1

[Masahiro Yamada]

Hi Olof and Arnd,

Please apply this series to ARM-SOC for the next merge window.

Thanks
Masahiro Yamada



Masahiro Yamada (3):
  ARM: dts: uniphier: change the external bus address mapping
  ARM: dts: uniphier: add ProXstream2 Vodka board support
  ARM: dts: uniphier: add ProXstream2 Gentil board support

 arch/arm/boot/dts/Makefile|  4 +-
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts|  5 +-
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts   |  5 +-
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts   |  5 +-
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts   |  5 +-
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts   |  5 +-
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++
 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts  | 79 +++
 8 files changed, 171 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts

-- 
1.9.1

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

[PATCH 3/3] ARM: dts: uniphier: add ProXstream2 Gentil board support

[Masahiro Yamada]

Initial version of DTS for ProXstream2 Gentil board.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/Makefile|  1 +
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++
 2 files changed, 80 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9232018..2e1bc82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -673,6 +673,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-sld8-ref.dtb \
+   uniphier-proxstream2-gentil.dtb \
uniphier-proxstream2-vodka.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts 
b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
new file mode 100644
index 000..3ea2a87
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Gentil Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL 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 file 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 file 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/ "uniphier-proxstream2.dtsi"
+
+/ {
+   model = "UniPhier ProXstream2 Gentil Board";
+   compatible = "socionext,proxstream2-gentil", "socionext,proxstream2";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   i2c0 = 
+   i2c4 = 
+   i2c5 = 
+   i2c6 = 
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
1.9.1

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

[PATCH 01/13] ARM: add some L220 DT settings

[Linus Walleij]

The RealView ARM11MPCore enables parity, eventmon and shared
override in the cache controller through its current boardfile,
but the code and DT bindings for the ARM L220 is currently
lacking the ability to set this up from DT. Add the required
bool parameters.

Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij 
---
I know this patch mixes code and DT changes but it is silly to
split such a small patch. Will submit this to Russell's patch
tracker if it looks OK to the DT people. (Or if they are quiet.)
---
 Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
 arch/arm/mm/cache-l2x0.c   | 15 +++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
b/Documentation/devicetree/bindings/arm/l2cc.txt
index 06c88a4d28ac..4d262e9b3464 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -67,12 +67,14 @@ Optional properties:
   disable if zero.
 - arm,prefetch-offset : Override prefetch offset value. Valid values are
   0-7, 15, 23, and 31.
-- arm,shared-override : The default behavior of the pl310 cache controller with
-  respect to the shareable attribute is to transform "normal memory
-  non-cacheable transactions" into "cacheable no allocate" (for reads) or
-  "write through no write allocate" (for writes).
+- arm,shared-override : The default behavior of the PL220 or PL310 cache
+  controllers with respect to the shareable attribute is to transform "normal
+  memory non-cacheable transactions" into "cacheable no allocate" (for reads)
+  or "write through no write allocate" (for writes).
   On systems where this may cause DMA buffer corruption, this property must be
   specified to indicate that such transforms are precluded.
+- arm,parity-enable : enable parity checking on the L2 cache (PL220 only).
+- arm,eventmon-enable : enable the event monitor on the L2 cache (PL220 only).
 - prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
   (forcibly enable), property absent (retain settings set by firmware)
 - prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 493692d838c6..d4e9fa2594f3 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1060,6 +1060,21 @@ static void __init l2x0_of_parse(const struct 
device_node *np,
val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
}
 
+   if (of_property_read_bool(np, "arm,parity-enable")) {
+   mask &= ~L2C_AUX_CTRL_PARITY_ENABLE;
+   val |= L2C_AUX_CTRL_PARITY_ENABLE;
+   }
+
+   if (of_property_read_bool(np, "arm,eventmon-enable")) {
+   mask &= ~L2C_AUX_CTRL_EVTMON_ENABLE;
+   val |= L2C_AUX_CTRL_EVTMON_ENABLE;
+   }
+
+   if (of_property_read_bool(np, "arm,shared-override")) {
+   mask &= ~L2C_AUX_CTRL_SHARED_OVERRIDE;
+   val |= L2C_AUX_CTRL_SHARED_OVERRIDE;
+   }
+
ret = l2x0_cache_size_of_parse(np, aux_val, aux_mask, , SZ_256K);
if (ret)
return;
-- 
2.4.3

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

[PATCH v2 1/3] extcon: arizona: Add extcon specific device tree binding document

[Charles Keepax]

Subystem specific bindings for the Arizona devices are being factored
out of the MFD binding document into seperate documents for each
subsystem. This patch adds a binding document that covers the existing
extcon specific bindings.

Acked-by: Chanwoo Choi 
Signed-off-by: Charles Keepax 
---

Changes since v1:
 - Added more commit message

Thanks,
Charles

 .../devicetree/bindings/extcon/extcon-arizona.txt  |   15 +++
 MAINTAINERS|1 +
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
new file mode 100644
index 000..e1705fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -0,0 +1,15 @@
+Cirrus Logic Arizona class audio SoCs
+
+These devices are audio SoCs with extensive digital capabilities and a range
+of analogue I/O.
+
+This document lists Extcon specific bindings, see the primary binding document:
+  ../mfd/arizona.txt
+
+Optional properties:
+
+  - wlf,hpdet-channel : Headphone detection channel.
+ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
+ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
+If this node is not mentioned or if the value is unknown, then
+headphone detection mode is set to HPDETL.
diff --git a/MAINTAINERS b/MAINTAINERS
index fb2ba3d..915f9ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11380,6 +11380,7 @@ T:  git 
git://opensource.wolfsonmicro.com/linux-2.6-audioplus
 W: http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices
 S: Supported
 F: Documentation/hwmon/wm83??
+F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.5

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

[PATCH v2 3/3] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Charles Keepax]

Binding documentation has been added in new subsystem specific binding
documents. This patch removes the now duplicate documentation from the
MFD documentation. Also whilst we are at it add a missing maintainers
entry for the MFD binding document.

Signed-off-by: Charles Keepax 
Acked-by: Lee Jones 
---

No change since v1.

Thanks,
Charles

 Documentation/devicetree/bindings/mfd/arizona.txt |   30 ++--
 MAINTAINERS   |1 +
 2 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..077c4fe 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -30,21 +30,9 @@ Required properties:
   - #gpio-cells : Must be 2. The first cell is the pin number and the
 second cell is used to specify optional parameters (currently unused).
 
-  - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device,
-as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
-  - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102,
-wm5110, wm8280, wm8998, wm1814)
-
-  - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102,
-wm5110, wm8280, wm8998, wm1814)
-
-  - SPKVDD-supply : Speaker driver power supply (wm8997)
-
 Optional properties:
 
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
-  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
 
   - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
 for the appropriate values can found in . If
@@ -67,21 +55,9 @@ Optional properties:
 present, the number of values should be less than or equal to the
 number of inputs, unspecified inputs will use the chip default.
 
-  - wlf,hpdet-channel : Headphone detection channel.
-ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
-ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
-If this node is not mentioned or if the value is unknown, then
-headphone detection mode is set to HPDETL.
-
-  - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
-they are being externally supplied. As covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional subnodes:
-  - ldo1 : Initial data for the LDO1 regulator, as covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
-  - micvdd : Initial data for the MICVDD regulator, as covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
+Also see child specific device properties:
+  Regulator - ../regulator/arizona-regulator.txt
+  Extcon- ../extcon/extcon-arizona.txt
 
 Example:
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 0e0889b..047f5d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11382,6 +11382,7 @@ S:  Supported
 F: Documentation/hwmon/wm83??
 F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
 F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
+F: Documentation/devicetree/bindings/mfd/arizona.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.5

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

[PATCH v2 2/3] regulator: arizona: Add regulator specific device tree binding document

[Charles Keepax]

Subystem specific bindings for the Arizona devices are being factored
out of the MFD binding document into seperate documents for each
subsystem. This patch adds a binding document that covers the existing
regulator specific bindings.

Signed-off-by: Charles Keepax 
---

Changes since v1:
 - Added more commit message

Thanks,
Charles

 .../bindings/regulator/arizona-regulator.txt   |   34 
 MAINTAINERS|1 +
 2 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/arizona-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt 
b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt
new file mode 100644
index 000..25bb7f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt
@@ -0,0 +1,34 @@
+Cirrus Logic Arizona class audio SoCs
+
+These devices are audio SoCs with extensive digital capabilities and a range
+of analogue I/O.
+
+This document lists regulator specific bindings, see the primary binding
+document:
+  ../mfd/arizona.txt
+
+Required properties:
+
+  - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device,
+as covered in regulator.txt
+
+  - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102,
+wm5110, wm8280, wm8998, wm1814)
+
+  - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102,
+wm5110, wm8280, wm8998, wm1814)
+
+  - SPKVDD-supply : Speaker driver power supply (wm8997)
+
+Optional properties:
+  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
+
+  - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
+they are being externally supplied. As covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional subnodes:
+  - ldo1 : Initial data for the LDO1 regulator, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
+  - micvdd : Initial data for the MICVDD regulator, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 915f9ec..0e0889b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11381,6 +11381,7 @@ W:  
http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices
 S: Supported
 F: Documentation/hwmon/wm83??
 F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
+F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.5

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

Re: [PATCH 0/3] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1

[Arnd Bergmann]

On Thursday 15 October 2015 18:05:31 Masahiro Yamada wrote:
> Hi Olof and Arnd,
> 
> Please apply this series to ARM-SOC for the next merge window.
> 

Applied the first patch, but not the other two, which look slightly wrong.
Can you check and send them again?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Arnd Bergmann]

On Thursday 15 October 2015 18:05:33 Masahiro Yamada wrote:
> +   aliases {
> +   serial0 = 
> +   serial1 = 
> +   serial2 = 
> +   i2c0 = 
> +   i2c4 = 
> +   i2c5 = 
> +   i2c6 = 
> 

This looks like a typo, you probably mean

   i2c0 = 
   i2c1 = 
   i2c2 = 
   i2c3 = 

Can you re-send this?

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

Re: [PATCH 3/3] ARM: BCM: Add SMP support for Broadcom NSP

[Jon Mason]

On Wed, Oct 14, 2015 at 06:40:04PM -0400, Jon Mason wrote:
> On Thu, Oct 15, 2015 at 12:26:25AM +0200, Hauke Mehrtens wrote:
> > On 10/14/2015 07:47 PM, Kapil Hali wrote:
> > > Add SMP support for Broadcom's Northstar Plus SoC,
> > > cpu enable method and pen_release procedures. This
> > > changes also consolidates iProc family's - BCM NSP
> > > and BCM Kona, SMP handling in a common file.
> > 
> > This will probably also work on normal Northstar CPUs without changes.
> 
> I think all that needs to be changed is adding to
> arch/arm/boot/dts/bcm4708.dts
> 
> +   enable-method = "brcm,bcm-nsp-smp";
> +   secondary-boot-reg = <0x0400>;
> 
> But I have not been able to confirm that yet.

I was able to confirm it on my BCM94708 SVK.  I'll send out the patch
which enables it shortly.

Thanks,
Jon

> 
> Thanks,
> Jon
> 
> > 
> > > Northstar Plus SoC is based on ARM Cortex-A9
> > > revision r3p0 which requires configuration for ARM
> > > Errata 764369 for SMP. This change adds the needed
> > > configuration option.
> > > 
> > > Signed-off-by: Kapil Hali 
> > > ---
> > >  arch/arm/mach-bcm/Kconfig   |   2 +
> > >  arch/arm/mach-bcm/Makefile  |   8 +-
> > >  arch/arm/mach-bcm/bcm_nsp.h |  19 
> > >  arch/arm/mach-bcm/headsmp.S |  37 
> > >  arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 142 
> > > ++--
> > >  5 files changed, 197 insertions(+), 11 deletions(-)
> > >  create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
> > >  create mode 100644 arch/arm/mach-bcm/headsmp.S
> > >  rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)
> > > 
> > > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > > index 1679fa4..2e9dbb5 100644
> > > --- a/arch/arm/mach-bcm/Kconfig
> > > +++ b/arch/arm/mach-bcm/Kconfig
> > > @@ -40,6 +40,8 @@ config ARCH_BCM_NSP
> > >   select ARCH_BCM_IPROC
> > >   select ARM_ERRATA_754322
> > >   select ARM_ERRATA_775420
> > > + select ARM_ERRATA_764369 if SMP
> > > + select HAVE_SMP
> > >   help
> > > Support for Broadcom Northstar Plus SoC.
> > > Broadcom Northstar Plus family of SoCs are used for switching control
> > > diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> > > index 892261f..36a4ca30 100644
> > > --- a/arch/arm/mach-bcm/Makefile
> > > +++ b/arch/arm/mach-bcm/Makefile
> > > @@ -14,7 +14,11 @@
> > >  obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
> > >  
> > >  # Northstar Plus
> > > -obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
> > > +obj-$(CONFIG_ARCH_BCM_NSP)   += bcm_nsp.o
> > > +
> > > +ifeq ($(CONFIG_ARCH_BCM_NSP),y)
> > > +obj-$(CONFIG_SMP)+= headsmp.o platsmp.o
> > > +endif
> > >  
> > >  # BCM281XX
> > >  obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
> > > @@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)+= board_bcm281xx.o
> > >  obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o
> > >  
> > >  # BCM281XX and BCM21664 SMP support
> > > -obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
> > > +obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
> > >  
> > >  # BCM281XX and BCM21664 L2 cache control
> > >  obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
> > > diff --git a/arch/arm/mach-bcm/bcm_nsp.h b/arch/arm/mach-bcm/bcm_nsp.h
> > > new file mode 100644
> > > index 000..58e1e80
> > > --- /dev/null
> > > +++ b/arch/arm/mach-bcm/bcm_nsp.h
> > > @@ -0,0 +1,19 @@
> > > +/*
> > > + * Copyright (C) 2015 Broadcom Corporation
> > > + *
> > > + * This program 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 version 2.
> > > + *
> > > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > > + * kind, whether express or implied; without even the implied warranty
> > > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#ifndef __BCM_NSP_H
> > > +#define __BCM_NSP_H
> > > +
> > > +extern void nsp_secondary_startup(void);
> > > +
> > > +#endif /* __BCM_NSP_H */
> > > diff --git a/arch/arm/mach-bcm/headsmp.S b/arch/arm/mach-bcm/headsmp.S
> > > new file mode 100644
> > > index 000..0da13b2
> > > --- /dev/null
> > > +++ b/arch/arm/mach-bcm/headsmp.S
> > > @@ -0,0 +1,37 @@
> > > +/*
> > > + * Copyright (C) 2015 Broadcom Corporation
> > > + *
> > > + * This program 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 version 2.
> > > + *
> > > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > > + * kind, whether express or implied; without even the implied warranty
> > > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more 

Re: [PATCH 1/3] dt-bindings: add SMP enable-method for Broadcom NSP

[Kapil Hali]

On 10/15/2015 3:57 AM, Hauke Mehrtens wrote:
> On 10/14/2015 07:46 PM, Kapil Hali wrote:
>> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
>> Northstar Plus CPU to the 32-bit ARM CPU device tree binding
>> documentation file and create a new binding documentation for
>> Northstar Plus CPU pen-release mechanism.
>>
>> Signed-off-by: Kapil Hali 
>> ---
>>  .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   | 36 
>> ++
>>  Documentation/devicetree/bindings/arm/cpus.txt |  1 +
>>  2 files changed, 37 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt 
>> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> new file mode 100644
>> index 000..8506da7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> @@ -0,0 +1,36 @@
>> +Broadcom Northstar Plus SoC CPU Enable Method
>> +-
>> +This binding defines the enable method used for starting secondary
>> +CPUs in the following Broadcom SoCs:
>> +  BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
>> +
>> +The enable method is specified by defining the following required
>> +properties in the "cpus" device tree node:
>> +  - enable-method = "brcm,bcm-nsp-smp";
>> +  - secondary-boot-reg = <...>;
>> +
>> +The secondary-boot-reg property is a u32 value that specifies the
>> +physical address of the register used to request the ROM holding pen
>> +code release a secondary CPU.
>> +
>> +Example:
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +enable-method = "brcm,bcm-nsp-smp";
>> +secondary-boot-reg = <0x042c>;
> 
> Isn't this some offset in a SRAM? If this is a SRAM it should be handled
> like it is done in some other SoC code.
> 
It is an internal SKU region. Is it handled differently in rest of the 
SoCs? What is that method?

>> +
>> +cpu0: cpu@0 {
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a9";
>> +next-level-cache = <>;
>> +reg = <0>;
>> +};
>> +
>> +cpu1: cpu@1 {
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a9";
>> +next-level-cache = <>;
>> +reg = <1>;
>> +};
>> +};
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
>> b/Documentation/devicetree/bindings/arm/cpus.txt
>> index 91e6e5c..1172d9b 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
>> @@ -190,6 +190,7 @@ nodes to be present and contain the properties described 
>> below.
>>  "allwinner,sun6i-a31"
>>  "allwinner,sun8i-a23"
>>  "arm,psci"
>> +"brcm,bcm-nsp-smp"
>>  "brcm,brahma-b15"
>>  "marvell,armada-375-smp"
>>  "marvell,armada-380-smp"
>>
> 
Thanks,
Kapil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Rob Herring]

On Thu, Oct 15, 2015 at 9:25 AM, WingMan Kwok  wrote:
> On TI's Keystone platforms, several peripherals such as the
> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> require the use of a SerDes for converting SoC parallel data into
> serialized data that can be output over a high-speed electrical
> interface, and also converting high-speed serial input data
> into parallel data that can be processed by the SoC.  The
> SerDeses used by those peripherals, though they may be different,
> are largely similar in functionality and setup.
>
> This patch provides a SerDes phy driver implementation that can be
> used by the above mentioned peripheral drivers to configure their
> respective SerDeses.
>
> v1:
> - see cover letter for review comments addressed.
>
> Signed-off-by: WingMan Kwok 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
>  drivers/phy/Kconfig  |8 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-keystone-serdes.c| 2373 
> ++
>  4 files changed, 2660 insertions(+)
>  create mode 100644 drivers/phy/phy-keystone-serdes.c
>
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 9cf9446..4dca271 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -115,4 +115,282 @@ sata_phy: phy@4A096000 {
> clock-names = "sysclk", "refclk";
> syscon-pllreset = <_conf 0x3fc>;
> #phy-cells = <0>;
> +
> +TI Keystone SerDes PHY
> +==
> +
> +Required properties:
> + - compatible: should be one of
> +   * "ti,keystone-serdes-gbe"
> +   * "ti,keystone-serdes-xgbe"
> +   * "ti,keystone-serdes-pcie"

These are different blocks or different modes of the same block? It's
fine if the former. If the latter, then you should have a single
compatible and then have a mode property. Perhaps phy-connection-type
from ePAPR ethernet binding can be extended.


> + - reg:
> +   * base address and length of the SerDes register set
> + - reg-names:
> +   * "serdes"
> +   - name of the reg SerDes register set

reg-names is kind of pointless with only 1.

> + - #phy-cells:
> +   * From the generic phy bindings, must be 0;
> + - num-lanes:
> +   * Number of lanes in SerDes.
> +
> +Optional properties:
> + - syscon-peripheral:
> +   * Handle to the subsystem register region of the peripheral
> + inside which the SerDes exists.
> + - syscon-link:
> +   * Handle to the Link register region of the peripheral inside
> + which the SerDes exists.  Example: it is the PCSR register
> + region in the case of 10gbe.
> + - rx-force-enable:
> +   * Include this property if receiver attenuation and boost are
> + to be configured with specific values defined in rx-force.
> + - link-rate-kbps:
> +   * SerDes link rate to be configured, in kbps.
> +
> +
> +For gbe and 10gbe SerDes, it is optional to represent each lane as
> +a sub-node, which can be enabled or disabled individually using
> +the "status" property.
> +
> +Required properties (lane sub-node):
> + - reg:
> +   * lane number
> +
> +Optional properties (lane sub-node):
> + - control-rate:
> +   * Lane control rate
> +   0: full rate
> +   1: half rate
> +   2: quarter rate
> + - rx-start:
> +   * Initial lane rx equalizer attenuation and boost configurations.
> +   * Must be array of 2 integers.
> + - rx-force:
> +   * Forced lane rx equalizer attenuation and boost configurations.
> +   * Must be array of 2 integers.
> + - tx-coeff:
> +   * Lane c1, c2, cm, attenuation and regulator output voltage
> + configurations.
> +   * Must be array of 5 integers.
> + - loopback:
> +   * Include this property to enable loopback at the SerDes
> + lane level.

This seems overly complicated. Do you really expect these to be
different per lane?

> +
> +Example for Keystone K2E GBE:
> +-
> +
> +gbe_serdes0: gbe_serdes@232a000 {
> +   #phy-cells  = <0>;
> +   compatible  = "ti,keystone-serdes-gbe";
> +   reg = <0x0232a000 0x2000>;
> +   reg-names   = "serdes";
> +   link-rate-kbps  = <125>;
> +   num-lanes   = <4>;
> +   lanes {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   lane@0 {
> +   /*loopback;*/
> +   reg = <0>;
> +   control-rate= <2>; /* quart */
> +   rx-start= <7 5>;
> +   rx-force= <1 1>;
> +   tx-coeff= <0 0 0 12 4>;
> +  

Re: [PATCH 3/3] ARM: BCM: Add SMP support for Broadcom NSP

[Kapil Hali]

On 10/15/2015 3:56 AM, Hauke Mehrtens wrote:
> On 10/14/2015 07:47 PM, Kapil Hali wrote:
>> Add SMP support for Broadcom's Northstar Plus SoC,
>> cpu enable method and pen_release procedures. This
>> changes also consolidates iProc family's - BCM NSP
>> and BCM Kona, SMP handling in a common file.
> 
> This will probably also work on normal Northstar CPUs without changes.
> 
I think, it should work for most of the variants of Northstar family, 
except for those which have a BOOTROM bug.

>> Northstar Plus SoC is based on ARM Cortex-A9
>> revision r3p0 which requires configuration for ARM
>> Errata 764369 for SMP. This change adds the needed
>> configuration option.
>>
>> Signed-off-by: Kapil Hali 
>> ---
>>  arch/arm/mach-bcm/Kconfig   |   2 +
>>  arch/arm/mach-bcm/Makefile  |   8 +-
>>  arch/arm/mach-bcm/bcm_nsp.h |  19 
>>  arch/arm/mach-bcm/headsmp.S |  37 
>>  arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 142 
>> ++--
>>  5 files changed, 197 insertions(+), 11 deletions(-)
>>  create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
>>  create mode 100644 arch/arm/mach-bcm/headsmp.S
>>  rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index 1679fa4..2e9dbb5 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -40,6 +40,8 @@ config ARCH_BCM_NSP
>>  select ARCH_BCM_IPROC
>>  select ARM_ERRATA_754322
>>  select ARM_ERRATA_775420
>> +select ARM_ERRATA_764369 if SMP
>> +select HAVE_SMP
>>  help
>>Support for Broadcom Northstar Plus SoC.
>>Broadcom Northstar Plus family of SoCs are used for switching control
>> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
>> index 892261f..36a4ca30 100644
>> --- a/arch/arm/mach-bcm/Makefile
>> +++ b/arch/arm/mach-bcm/Makefile
>> @@ -14,7 +14,11 @@
>>  obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
>>  
>>  # Northstar Plus
>> -obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
>> +obj-$(CONFIG_ARCH_BCM_NSP)  += bcm_nsp.o
>> +
>> +ifeq ($(CONFIG_ARCH_BCM_NSP),y)
>> +obj-$(CONFIG_SMP)   += headsmp.o platsmp.o
>> +endif
>>  
>>  # BCM281XX
>>  obj-$(CONFIG_ARCH_BCM_281XX)+= board_bcm281xx.o
>> @@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)   += board_bcm281xx.o
>>  obj-$(CONFIG_ARCH_BCM_21664)+= board_bcm21664.o
>>  
>>  # BCM281XX and BCM21664 SMP support
>> -obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
>> +obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
>>  
>>  # BCM281XX and BCM21664 L2 cache control
>>  obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
>> diff --git a/arch/arm/mach-bcm/bcm_nsp.h b/arch/arm/mach-bcm/bcm_nsp.h
>> new file mode 100644
>> index 000..58e1e80
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm/bcm_nsp.h
>> @@ -0,0 +1,19 @@
>> +/*
>> + * Copyright (C) 2015 Broadcom Corporation
>> + *
>> + * This program 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 version 2.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#ifndef __BCM_NSP_H
>> +#define __BCM_NSP_H
>> +
>> +extern void nsp_secondary_startup(void);
>> +
>> +#endif /* __BCM_NSP_H */
>> diff --git a/arch/arm/mach-bcm/headsmp.S b/arch/arm/mach-bcm/headsmp.S
>> new file mode 100644
>> index 000..0da13b2
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm/headsmp.S
>> @@ -0,0 +1,37 @@
>> +/*
>> + * Copyright (C) 2015 Broadcom Corporation
>> + *
>> + * This program 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 version 2.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +
>> +/*
>> + * iProc specific entry point for secondary CPUs.  This provides
>> + * a "holding pen" into which all secondary cores are held until
>> + * we are ready for them to initialise.
>> + */
>> +ENTRY(nsp_secondary_startup)
>> +mrc p15, 0, r0, c0, c0, 5
>> +and r0, r0, #15
>> +adr r4, 1f
>> +ldmia   r4, {r5, r6}
>> +sub r4, r4, r5
>> +add r6, r6, r4
>> +pen:ldr r7, [r6]
>> +cmp r7, r0
>> +bne pen
>> +
>> +bsecondary_startup
>> +
>> +1:  .long   .
>> +.long   pen_release
>> +
>> +ENDPROC(nsp_secondary_startup)

Re: [PATCH v2] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board

[Arnd Bergmann]

On Thursday 15 October 2015 20:32:05 Masahiro Yamada wrote:
> The IRQ signal from external devices on this board is connected to
> the XIRQ4 pin of the SoC.  The IRQ number should be 52, not 50.
> 
> Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b 
> SoC/board support")
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v2:
>   - change IRQ to 52
> 
>  arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts 
> b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
> index 33963ac..f80f772 100644
> --- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
> +++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
> @@ -85,7 +85,7 @@
>  };
>  
>   {
> - interrupts = <0 50 4>;
> + interrupts = <0 52 4>;
>  };
>  
>   {
> 

Applied to fixes, thanks!

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

Re: [PATCH 3/3] ARM: at91/defconfig: update sama5 defconfig

[Ludovic Desroches]

On Thu, Oct 15, 2015 at 03:24:51PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 14/10/2015 at 14:11:24 +0200, Ludovic Desroches wrote :
> > Add SAMA5D2 SoC plus Atmel flexcom and Atmel sdhci devices.
> > 
> > Signed-off-by: Ludovic Desroches 
> > ---
> >  arch/arm/configs/sama5_defconfig | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> It is probably worth updating the multi_v7_defconfig too (in a separate
> patch).
> 

Maybe I have to send a whole defconfig update . I mean when you do
savedefconfig, you have more changes. I won't send each one separately. I
have kept changes which were in relation with the stuff I had.

Or I can send a defconfig update from the savedefconfig and then add
sama5d2, flexcom and sdhci.

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

Re: [PATCH 3/3] ARM: at91/defconfig: update sama5 defconfig

[Nicolas Ferre]

Le 15/10/2015 17:31, Ludovic Desroches a écrit :
> On Thu, Oct 15, 2015 at 03:24:51PM +0200, Alexandre Belloni wrote:
>> Hi,
>>
>> On 14/10/2015 at 14:11:24 +0200, Ludovic Desroches wrote :
>>> Add SAMA5D2 SoC plus Atmel flexcom and Atmel sdhci devices.
>>>
>>> Signed-off-by: Ludovic Desroches 
>>> ---
>>>  arch/arm/configs/sama5_defconfig | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>> It is probably worth updating the multi_v7_defconfig too (in a separate
>> patch).
>>
> 
> Maybe I have to send a whole defconfig update . I mean when you do
> savedefconfig, you have more changes. I won't send each one separately. I
> have kept changes which were in relation with the stuff I had.
> 
> Or I can send a defconfig update from the savedefconfig and then add
> sama5d2, flexcom and sdhci.

Actually you can do this for our own AT91 defconfigs.

For the multi_v7_defconfig I would recommend to simply make a patch with
our updates and let the arm-soc maintainer merge it with their current
one: I mean, they will manage the conflicts on this file anyway and the
changes to this file will not be part of one or our pull-requests but a
patch that they will handle separately: so no need to add more update
than the strictly needed ones on our end.

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

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Murali Karicheri]

On 10/15/2015 10:51 AM, Arnd Bergmann wrote:

On Thursday 15 October 2015 10:25:44 WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

v1:


cut-


+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.


The current code does not do this when compiled, which might be a
problem for distributors. Can you clarify the license?


Arnd,

Can you elaborate on this? I did a grep on the string "Redistributions 
in binary form must reproduce the above copyright" and I could find 
several instance of this. So I am not sure what you mean by "The current 
code does not do this when compiled".


Thanks
--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: fix gpio-keys wakeup-source property

[Sudeep Holla]

Hi Arnd,

On 15/10/15 15:57, Linus Walleij wrote:

On Tue, Oct 13, 2015 at 3:32 PM, Sudeep Holla  wrote:


The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
two boolean properties to enable gpio buttons as wakeup source:
1. "wakeup-source" or
2. the legacy "gpio-key,wakeup"

However juno, ste-snowball and emev2-kzm9d dts file have a undetected
"wakeup" property to indicate the wakeup source.

This patch fixes it by making use of "wakeup-source" property.

Cc: Simon Horman 
Cc: Magnus Damm 
Cc: Linus Walleij 
Signed-off-by: Sudeep Holla 


OK nice,
Reviewed-by: Linus Walleij 



Can you pick this up as fix for v4.3 with Ack from Simon and Linus
Walleij ? I will repost 2/2 as a part of bigger cleanup for v4.4

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

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/14/2015 11:41 AM, santosh shilimkar wrote:

10/14/2015 7:17 AM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs.
Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware
and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot
log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you
please
apply this series to v4.4 next please at your earliest opportunity.


I have picked up the series. Thanks for quick turnaround.


Thanks Santosh. Could you send this pull request for v4.4 next. We want 
this merged to our internal release and if this is on next branch it 
will help.


Thanks

Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] iio: mma8452: support either of the available interrupt pins

[Martin Kepplinger]

This change is important in order for everyone to be easily able to use the
driver for one of the supported accelerometer chips!

Until now, the driver blindly assumed that the INT1 interrupt line is wired
on a user's board. But these devices have 2 interrupt lines and can route
their interrupt sources to one of them. Now, if "INT2" is found and matches
i2c_client->irq, INT2 will be used.

The chip's default actually is INT2, which is why probably many boards will
have it wired and can make use of this.

Of course, this also falls back to assuming INT1, so for existing users
nothing will break. The new functionality is described in the bindings doc.

Signed-off-by: Martin Kepplinger 
---
changelog:
v4: use irq that matches client->irq, backwards compatible
v3: correctly assign irq if both pins are described in DT
v2: don't warn but normally handle if both pins are described in dts
thanks Mark Rutland
v1: initial post

 .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
 drivers/iio/accel/mma8452.c | 21 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e3c3746..3c10e85 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -7,13 +7,18 @@ Required properties:
 * "fsl,mma8453"
 * "fsl,mma8652"
 * "fsl,mma8653"
+
   - reg: the I2C address of the chip
 
 Optional properties:
 
   - interrupt-parent: should be the phandle for the interrupt controller
+
   - interrupts: interrupt mapping for GPIO IRQ
 
+  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
+interrupt line in use.
+
 Example:
 
mma8453fc@1d {
@@ -21,4 +26,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <>;
interrupts = <5 0>;
+   interrupt-names = "INT2";
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 1eccc2d..116a6e4 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
   MMA8452_INT_FF_MT;
int enabled_interrupts = MMA8452_INT_TRANS |
 MMA8452_INT_FF_MT;
+   int irq2;
 
-   /* Assume wired to INT1 pin */
-   ret = i2c_smbus_write_byte_data(client,
-   MMA8452_CTRL_REG5,
-   supported_interrupts);
-   if (ret < 0)
-   return ret;
+   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
+
+   if (irq2 == client->irq) {
+   dev_dbg(>dev, "using interrupt line INT2\n");
+   } else {
+   ret = i2c_smbus_write_byte_data(client,
+   MMA8452_CTRL_REG5,
+   supported_interrupts);
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(>dev, "using interrupt line INT1\n");
+   }
 
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
-- 
2.1.4

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

Re: [PATCH 01/13] ARM: add some L220 DT settings

[Rob Herring]

On Thu, Oct 15, 2015 at 8:46 AM, Linus Walleij  wrote:
> The RealView ARM11MPCore enables parity, eventmon and shared
> override in the cache controller through its current boardfile,
> but the code and DT bindings for the ARM L220 is currently
> lacking the ability to set this up from DT. Add the required
> bool parameters.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
> I know this patch mixes code and DT changes but it is silly to
> split such a small patch. Will submit this to Russell's patch
> tracker if it looks OK to the DT people. (Or if they are quiet.)
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
>  arch/arm/mm/cache-l2x0.c   | 15 +++
>  2 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
> b/Documentation/devicetree/bindings/arm/l2cc.txt
> index 06c88a4d28ac..4d262e9b3464 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -67,12 +67,14 @@ Optional properties:
>disable if zero.
>  - arm,prefetch-offset : Override prefetch offset value. Valid values are
>0-7, 15, 23, and 31.
> -- arm,shared-override : The default behavior of the pl310 cache controller 
> with
> -  respect to the shareable attribute is to transform "normal memory
> -  non-cacheable transactions" into "cacheable no allocate" (for reads) or
> -  "write through no write allocate" (for writes).
> +- arm,shared-override : The default behavior of the PL220 or PL310 cache

PL220 is something else:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0249b/CHDIIEAD.html


> +  controllers with respect to the shareable attribute is to transform "normal
> +  memory non-cacheable transactions" into "cacheable no allocate" (for reads)
> +  or "write through no write allocate" (for writes).

I seem to recall the PL310 TRM says this bit is different from the
L220 or the default is.

>On systems where this may cause DMA buffer corruption, this property must 
> be
>specified to indicate that such transforms are precluded.
> +- arm,parity-enable : enable parity checking on the L2 cache (PL220 only).

PL310 has parity.

> +- arm,eventmon-enable : enable the event monitor on the L2 cache (PL220 
> only).

and eventmon.

There's a slight problem here in that you can turn on these with DT,
but you can't turn them off as absence means don't touch. Maybe a
value of 0 should be allowed for disabling.

>  - prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
>(forcibly enable), property absent (retain settings set by firmware)
>  - prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 493692d838c6..d4e9fa2594f3 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1060,6 +1060,21 @@ static void __init l2x0_of_parse(const struct 
> device_node *np,
> val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
> }
>
> +   if (of_property_read_bool(np, "arm,parity-enable")) {
> +   mask &= ~L2C_AUX_CTRL_PARITY_ENABLE;
> +   val |= L2C_AUX_CTRL_PARITY_ENABLE;
> +   }
> +
> +   if (of_property_read_bool(np, "arm,eventmon-enable")) {
> +   mask &= ~L2C_AUX_CTRL_EVTMON_ENABLE;
> +   val |= L2C_AUX_CTRL_EVTMON_ENABLE;
> +   }
> +
> +   if (of_property_read_bool(np, "arm,shared-override")) {
> +   mask &= ~L2C_AUX_CTRL_SHARED_OVERRIDE;
> +   val |= L2C_AUX_CTRL_SHARED_OVERRIDE;
> +   }
> +
> ret = l2x0_cache_size_of_parse(np, aux_val, aux_mask, , 
> SZ_256K);
> if (ret)
> return;
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Arnd Bergmann]

On Thursday 15 October 2015 10:25:44 WingMan Kwok wrote:
> On TI's Keystone platforms, several peripherals such as the
> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> require the use of a SerDes for converting SoC parallel data into
> serialized data that can be output over a high-speed electrical
> interface, and also converting high-speed serial input data
> into parallel data that can be processed by the SoC.  The
> SerDeses used by those peripherals, though they may be different,
> are largely similar in functionality and setup.
> 
> This patch provides a SerDes phy driver implementation that can be
> used by the above mentioned peripheral drivers to configure their
> respective SerDeses.
> 
> v1:
>   - see cover letter for review comments addressed.
> 
> Signed-off-by: WingMan Kwok 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
>  drivers/phy/Kconfig  |8 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-keystone-serdes.c| 2373 
> ++
>  4 files changed, 2660 insertions(+)
>  create mode 100644 drivers/phy/phy-keystone-serdes.c

This is quite a bit of code. Are you very sure that this PHY is
not used on any other SoC family, and that it is not licensed
from a third party? I would hate to see multiple copies of
this getting merged into the kernel over time, so thename should
be chosen carefully to let the next person know when they have
related hardware.

> +
> +gbe_serdes0: gbe_serdes@232a000 {


make that phy@232a000, the name should be one of the usual identifiers,
not specific to the instance.

> +config PHY_TI_KEYSTONE_SERDES
> + tristate "TI Keystone SerDes PHY support"
> + depends on OF && ARCH_KEYSTONE
> + select GENERIC_PHY
> + help
> +   This option enables support for TI Keystone SerDes PHY found
> +   in peripherals GBE, 10GBE and PCIe.
> +

(ARCH_KEYSTONE || COMPILE_TEST) ?

> + * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the
> + * distribution.

The current code does not do this when compiled, which might be a
problem for distributors. Can you clarify the license?

> +#define reg_rmw(addr, value, mask) \
> + __raw_writel(((__raw_readl(addr) & (~(mask))) | \
> + (value & (mask))), (addr))

not endian safe, and potentially racy.

> +static inline void _kserdes_reset_cdr(void __iomem *sregs, int lane)
> +{
> + /* toggle signal detect */
> + _kserdes_force_signal_detect_low(sregs, lane);
> + mdelay(1);
> + _kserdes_force_signal_detect_high(sregs, lane);
> +}

Can you change the code so you can use msleep(1) here?

> +
> + do {
> + mdelay(10);
> + memset(lane_down, 0, sizeof(lane_down));
> +
> + link_up = _kserdes_check_link_status(dev, sregs,
> +  pcsr_regmap, lanes,
> +  lanes_enable,
> +  current_state, lane_down);
> +
> + /* if we did not get link up then wait 100ms
> +  * before calling it again
> +  */
> + if (link_up)
> + break;
> +
> + for (i = 0; i < lanes; i++) {
> + if ((lanes_enable & (1 << i)) && lane_down[i])
> + dev_dbg(dev,
> + "XGE: detected lane down on lane %d\n",
> + i);
> + }
> +
> + if (++retries > 100)
> + return -ETIMEDOUT;
> +
> + } while (!link_up);

an more importantly here. Blocking the CPU for over one second is not good.

Any use of mdelay() should have a comment explaining why you cannot use
msleep() in that instance.

> +
> +static int __init keystone_serdes_phy_init(void)
> +{
> + return platform_driver_register(_driver);
> +}
> +module_init(keystone_serdes_phy_init);
> +
> +static void __exit keystone_serdes_phy_exit(void)
> +{
> + platform_driver_unregister(_driver);
> +}
> +module_exit(keystone_serdes_phy_exit);

module_platform_driver()

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

Re: [linux-sunxi] Re: [PATCH 1/3] ARM: dts: sunxi: Fix interrupt-cells for [r]pio on A23/A31/A33/A80

[Hans de Goede]

Hi,

On 15-10-15 16:38, Arnd Bergmann wrote:

On Thursday 15 October 2015 16:28:45 Hans de Goede wrote:

When the gpio interrupt bindings where changed to add a bank to the
specifier list, the r_pio nodes of A23/A31/A33 where not updated to
match and neither was the pio node of the A80, this fixes this.

Signed-off-by: Hans de Goede 



Is this safe to apply by itself? I don't see any interrupts references
to these nodes, so I assume it's fine, but if there are any cross-dependencies
we need more careful planning.


Should be safe to apply by itself, later patches in this series introduce
the first interrupt users of these nodes, which is what made me notice
the mistake in them.

Regards,

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

Re: [PATCH 01/13] ARM: add some L220 DT settings

[Russell King - ARM Linux]

On Thu, Oct 15, 2015 at 03:46:41PM +0200, Linus Walleij wrote:
> The RealView ARM11MPCore enables parity, eventmon and shared
> override in the cache controller through its current boardfile,
> but the code and DT bindings for the ARM L220 is currently
> lacking the ability to set this up from DT. Add the required
> bool parameters.
> 
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
> I know this patch mixes code and DT changes but it is silly to
> split such a small patch. Will submit this to Russell's patch
> tracker if it looks OK to the DT people. (Or if they are quiet.)
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
>  arch/arm/mm/cache-l2x0.c   | 15 +++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
> b/Documentation/devicetree/bindings/arm/l2cc.txt
> index 06c88a4d28ac..4d262e9b3464 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -67,12 +67,14 @@ Optional properties:
>disable if zero.
>  - arm,prefetch-offset : Override prefetch offset value. Valid values are
>0-7, 15, 23, and 31.
> -- arm,shared-override : The default behavior of the pl310 cache controller 
> with
> -  respect to the shareable attribute is to transform "normal memory
> -  non-cacheable transactions" into "cacheable no allocate" (for reads) or
> -  "write through no write allocate" (for writes).
> +- arm,shared-override : The default behavior of the PL220 or PL310 cache
> +  controllers with respect to the shareable attribute is to transform "normal
> +  memory non-cacheable transactions" into "cacheable no allocate" (for reads)
> +  or "write through no write allocate" (for writes).
>On systems where this may cause DMA buffer corruption, this property must 
> be
>specified to indicate that such transforms are precluded.
> +- arm,parity-enable : enable parity checking on the L2 cache (PL220 only).
> +- arm,eventmon-enable : enable the event monitor on the L2 cache (PL220 
> only).

I don't think we should introduce a DT property for this: if we support
the event monitor, then the event monitor support code should be
controlling this bit.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: fix gpio-keys wakeup-source property

[Linus Walleij]

On Tue, Oct 13, 2015 at 3:32 PM, Sudeep Holla  wrote:

> The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
> two boolean properties to enable gpio buttons as wakeup source:
> 1. "wakeup-source" or
> 2. the legacy "gpio-key,wakeup"
>
> However juno, ste-snowball and emev2-kzm9d dts file have a undetected
> "wakeup" property to indictate the wakeup source.
>
> This patch fixes it by making use of "wakeup-source" property.
>
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: Linus Walleij 
> Signed-off-by: Sudeep Holla 

OK nice,
Reviewed-by: Linus Walleij 

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

Re: [PATCH 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Tony Lindgren]

* Peter Ujfalusi  [151015 00:13]:
> Tony,
> 
> On 10/12/2015 11:57 PM, Tony Lindgren wrote:
> > * Tony Lindgren  [150914 09:32]:
> >> * Peter Ujfalusi  [150914 01:54]:
> >>> Hi Tony,
> >>>
> >>> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
>  Hi,
> 
>  this series will enable analog audio (via onboard aic310x codec) for 
>  dra7-evm,
>  dra72-evm and am57xx-beagle-x15 boards.
>  In these board McASP3 is connected to the codec and for the McASP3 we 
>  needed to
>  have the DMA crossbar in place since the request lines are not mapped by
>  default.
> >>>
> >>> Did you had a chance to look at this series?
> >>
> >> Looks OK to me, will look at it more once we have the fixes merged.
> >>
> >> Paul may have comments on the hwmod chage, looks like you forgot
> >> to Cc him on it. Can you please resend that one with Paul in Cc?
> > 
> > Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
> > can pick up the hwmod change then after reviewing it.
> 
> Thanks for taking the DTS patches, however if Paul agrees with the way I 
> think we can handle the McASP in DRA7xx then the patch which adds the mcasp3 
> node to dra7.dtsi needs to be replaced by:

Oh OK so the clocks may change. Well please send a follow up patch on
that then.

BTW, we should not set status = "disabled" in the SoC specific dtsi files.
The internal devices are there and we're better off having a struct device
created for them. If someobdy really wants to "disable" some internal device
for yet to be seen good reason, it should be done in the board specific dts
file.

Regards,

Tony

> From b6733f9ca96a997fab3d0455783e875dd9ae032b Mon Sep 17 00:00:00 2001
> From: Peter Ujfalusi 
> Date: Tue, 24 Feb 2015 15:12:59 +0200
> Subject: [PATCH v2 03/12] ARM: DTS: dra7: Add McASP3 node
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 8fedddc35999..cde0a3cbf262 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1404,6 +1404,21 @@
>   status = "disabled";
>   };
>  
> + mcasp3: mcasp@48468000 {
> + compatible = "ti,dra7-mcasp-audio";
> + ti,hwmods = "mcasp3";
> + reg = <0x48468000 0x2000>;
> + reg-names = "mpu";
> + interrupts = ,
> +  ;
> + interrupt-names = "tx", "rx";
> + dmas = <_xbar 133>, <_xbar 132>;
> + dma-names = "tx", "rx";
> + clocks = <_aux_gfclk_mux>, <_ahclkx_mux>;
> + clock-names = "fck", "ahclkx";
> + status = "disabled";
> + };
> +
>   crossbar_mpu: crossbar@4a002a48 {
>   compatible = "ti,irq-crossbar";
>   reg = <0x4a002a48 0x130>;
> -- 
> 2.6.1
> 
> 
> 
> 
> -- 
> Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: sunxi: Fix interrupt-cells for [r]pio on A23/A31/A33/A80

[Hans de Goede]

When the gpio interrupt bindings where changed to add a bank to the
specifier list, the r_pio nodes of A23/A31/A33 where not updated to
match and neither was the pio node of the A80, this fixes this.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 1 +
 arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 98359f3..a97274a8 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -1102,7 +1102,7 @@
resets = <_rst 0>;
gpio-controller;
interrupt-controller;
-   #interrupt-cells = <2>;
+   #interrupt-cells = <3>;
#size-cells = <0>;
#gpio-cells = <3>;
 
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 828aaf5..ddb9890 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -647,6 +647,7 @@
resets = <_rst 0>;
gpio-controller;
interrupt-controller;
+   #interrupt-cells = <3>;
#address-cells = <1>;
#size-cells = <0>;
#gpio-cells = <3>;
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 5908e3d..1118bf5 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -594,7 +594,7 @@
clocks = <_gates 5>;
gpio-controller;
interrupt-controller;
-   #interrupt-cells = <2>;
+   #interrupt-cells = <3>;
#size-cells = <0>;
#gpio-cells = <3>;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: sun6i: Add mmc2_pins_a pinmux setting to sun6i-a31.dtsi

[Hans de Goede]

Add a pinmux setting for using mmc2 in regular 4 bit mode.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index a97274a8..83c1879 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -691,7 +691,15 @@
allwinner,pull = ;
};
 
-   mmc2_8bit_emmc_pins: mmc2@0 {
+   mmc2_pins_a: mmc2@0 {
+   allwinner,pins = "PC6", "PC7", "PC8", "PC9",
+"PC10", "PC11";
+   allwinner,function = "mmc2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   mmc2_8bit_emmc_pins: mmc2@1 {
allwinner,pins = "PC6", "PC7", "PC8", "PC9",
 "PC10", "PC11", "PC12",
 "PC13", "PC14", "PC15",
-- 
2.5.0

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

[PATCH 3/3] ARM: dts: sun6i: Add a dts file for the Sinovoip BPI-M2 board

[Hans de Goede]

The Sinovoip BPI-M2 is a SBC board based on the A31s SoC it features
1G RAM, a microsd slot, Gbit ethernet, 4 usb-a USB-2 ports, ir receiver,
stereo headphone jack and hdmi video output.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 194 +++
 2 files changed, 195 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 389f30d..46a163d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
sun6i-a31s-cs908.dtb \
+   sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
 dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-bananapi.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts 
b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
new file mode 100644
index 000..db7fa13
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -0,0 +1,194 @@
+/*
+ * Copyright 2015 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL 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 "sun6i-a31s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include 
+
+/ {
+   model = "Sinovoip BPI-M2";
+   compatible = "sinovoip,bpi-m2", "allwinner,sun6i-a31s";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_bpi_m2>;
+
+   blue {
+   label = "bpi-m2:blue:usr";
+   gpios = < 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+   };
+
+   green {
+   label = "bpi-m2:green:usr";
+   gpios = < 6 10 GPIO_ACTIVE_HIGH>; /* PG10 */
+   };
+
+   red {
+   label = "bpi-m2:red:usr";
+   gpios = < 6 5 GPIO_ACTIVE_HIGH>; /* PG5 */
+   };
+   };
+
+   mmc2_pwrseq: mmc2_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwrseq_pin_bpi_m2>;
+   reset-gpios = <_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 WIFI_EN */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_rgmii_a>, <_phy_reset_pin_bpi_m2>;
+   phy = <>;
+   phy-mode = "rgmii";
+   snps,reset-gpio = < 0 21 GPIO_ACTIVE_HIGH>; /* PA21 */
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 3>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   

Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Marek Vasut]

On Thursday, October 15, 2015 at 04:10:08 PM, Graham Moore wrote:
> On 08/21/2015 04:20 AM, Marek Vasut wrote:
> > From: Graham Moore 
> > 
> > Add support for the Cadence QSPI controller. This controller is
> > present in the Altera SoCFPGA SoCs and this driver has been tested
> > on the Cyclone V SoC.
> > 
> > Signed-off-by: Graham Moore 
> > Signed-off-by: Marek Vasut 
> 
> [...]
> 
> Hi, just checking in.  Are there any more changes to this driver?

This will need to be ported on top of the MTD changes by Cyrille , I have
it in my pipeline, but it wasn't done yet.

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: sunxi: Fix interrupt-cells for [r]pio on A23/A31/A33/A80

[Arnd Bergmann]

On Thursday 15 October 2015 16:28:45 Hans de Goede wrote:
> When the gpio interrupt bindings where changed to add a bank to the
> specifier list, the r_pio nodes of A23/A31/A33 where not updated to
> match and neither was the pio node of the A80, this fixes this.
> 
> Signed-off-by: Hans de Goede 
> 

Is this safe to apply by itself? I don't see any interrupts references
to these nodes, so I assume it's fine, but if there are any cross-dependencies
we need more careful planning.

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

Re: [PATCHv4 3/3] devicetree: Add led-backlight binding

[Tomi Valkeinen]

Hi Rob,

On 15/10/15 16:46, Rob Herring wrote:

>> At some point I got feedback that the DT maintainers don't have time to
>> look at each individual driver binding, but rely on the subsystem
>> maintainers to handle them. Maybe I misunderstood that.
> 
> True, but that doesn't mean to not copy us. If we didn't want to be
> copied, we would update MAINTAINERS.

Ok.

>>> Why do we need 2 levels of LED nodes?
>>
>> Sorry, didn't get that. What do you mean with 2 levels?
> 
> You have the node the "leds" phandle points to which is the actual LED
> device and then this node which is just backlight properties. And then
> presumably another phandle in the panel device to point to the
> backlight device.

Ok, I see what you mean.

Well, I have to say this is far from perfect. I initially pushed for a
PWM driver for the LED chip we use (tlc591xx), which would have allowed
us to use pwm-backlight driver. But Andrew was using the same chip for
more LED-ish use cases, for which a LED driver was more suitable.

But what I think we really should have is a more generic way to
represent output pins, so that GPIOs (well, GPOs really), PWMs and
current controlled outputs would all be done the same way.

It was rather difficult to use the LED driver and LED bindings for this,
as (afaics) they were really never designed to be used for anything else
than for simple LEDs (i.e. a LED connected directly to the LED chip).
The flash support was added later, but that's almost as simple as the
first case.

>> These are for the backlight, not for the LED chip. So "LED" here is a
>> chip that produces (most likely) a PWM signal, and "backlight" is the
>> collection of components that use the PWM to produce the backlight
>> itself, and use the power-supply and gpios.
> 
> Okay, it wasn't clear that leds points to the LED controller node. The

No, it doesn't point to the main LED node (the one having 'compatible').
It points to a child node.

> example made it seem as it was the device. We already have a way to
> describe LEDs and that is as child nodes of the LED controller node.

True, but those child nodes are very limited. As I see it, those child
nodes really describe the outputs of the LED chip, not what's on the
other end of the lines.

If on the other end of the lines is a more complex device, we need a
proper device driver for it, with a proper DT node with compatible
property etc.

Now, one could argue that a "backlight" that gets the LED signal from a
LED chip is really just a simple LED. But there are complications:

- Our board needs a GPIO to enable the backlight. I can't say what
exactly the GPIO does as my HW skills don't go far enough, but all this
is after the LED chip. I also see the circuitry using powers, which in
our case happen to be always on so we don't need to enable them explicitly.

- We need a backlight device/driver (because of the Linux SW stack).

So, maybe it would be possible to construct all that in a LED child
node, and the LED driver would create a child device for the nodes which
have 'compatible' property. But then, that would be very different from
pwm-backlight, and the parent-child relationships are usually used to
indicate a control relationship, right?

The led-backlight in these patches is very much similar to pwm-backlight.

> Please follow what was done for flash LEDs (leds/common.txt).

The flash support is quite simple. I'm not sure how I could do the same
for the backlight, as I described above.

> What's wrong with the existing pwm-backlight binding in the PWM case?

Nothing, if there's a PWM driver. But if the LED chip is modelled as a
LED driver, pwm-backlight is out. I think there are two kinds of LED
chips, PWM ones and current-controlling ones. And then there are the PWM
devices which are clearly PWM ones.

>>> Describe the h/w, not what you want for a driver.
>>
>> I think this describes the HW quite well. The LED chip works fine
>> without any of the properties here, and these are specific to the
>> backlight part of the board.
> 
> A more complete example would be helpful here.

Of our HW? I can't give the schematics but I hope I described it enough
above.

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH] mtd: document linux-specific partition parser DT binding

[Linus Walleij]

The Linux code in drivers/mtd/maps/physmap_of.c will optionally
look for this binding for hints on a partition type to look for
in the MTD. It was added in commit 9d5da3a9b849
"mtd: extend physmap_of to let the device tree specify the parition probe"
but no corresponding device tree binding was added. Fix this.

Cc: devicetree@vger.kernel.org
Cc: Jason Gunthorpe 
Cc: Liviu Dudau 
Reported-by: Liviu Dudau 
Signed-off-by: Linus Walleij 
---
 Documentation/devicetree/bindings/mtd/mtd-physmap.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt 
b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index 4a0a48bf4ecb..0dee084651da 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -26,6 +26,9 @@ file systems on embedded devices.
  - linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
+ - linux,part-probe: a flash partition type to look for, using the
+   Linux-internal partition naming scheme, e.g. "afs" for the ARM
+   Flash footers.
  - use-advanced-sector-protection: boolean to enable support for the
advanced sector protection (Spansion: PPB - Persistent Protection
Bits) locking.
-- 
2.4.3

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

Re: [PATCH 3/3] ARM: at91/defconfig: update sama5 defconfig

[Alexandre Belloni]

Hi,

On 14/10/2015 at 14:11:24 +0200, Ludovic Desroches wrote :
> Add SAMA5D2 SoC plus Atmel flexcom and Atmel sdhci devices.
> 
> Signed-off-by: Ludovic Desroches 
> ---
>  arch/arm/configs/sama5_defconfig | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
It is probably worth updating the multi_v7_defconfig too (in a separate
patch).


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: at91/dt: fix "disabled" property on at91rm9200

[Alexandre Belloni]

On 13/10/2015 at 13:24:24 +0200, Michael Opdenacker wrote :
> Fix instances of "disable" instead of "disabled"
> in the at91rm9200 dtsi.
> 
> Signed-off-by: Michael Opdenacker 
Acked-by: Alexandre Belloni 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv4 3/3] devicetree: Add led-backlight binding

[Rob Herring]

On Thu, Oct 15, 2015 at 7:17 AM, Tomi Valkeinen  wrote:
> Hi Rob,
>
> On 13/10/15 17:21, Rob Herring wrote:
>> On Wed, Sep 30, 2015 at 4:32 AM, Tomi Valkeinen  
>> wrote:
>>> Add DT binding for led-backlight.
>>
>> Please use get_maintainers.pl.
>
> At some point I got feedback that the DT maintainers don't have time to
> look at each individual driver binding, but rely on the subsystem
> maintainers to handle them. Maybe I misunderstood that.

True, but that doesn't mean to not copy us. If we didn't want to be
copied, we would update MAINTAINERS.

I wouldn't call this one an individual driver either. This is very
much a generic binding which we do want to review.

>
>>> Signed-off-by: Tomi Valkeinen 
>>> Cc: devicetree@vger.kernel.org
>>> ---
>>>  .../bindings/video/backlight/led-backlight.txt | 30 
>>> ++
>>>  1 file changed, 30 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/video/backlight/led-backlight.txt 
>>> b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>>> new file mode 100644
>>> index ..d4621d7414bc
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
>>> @@ -0,0 +1,30 @@
>>> +led-backlight bindings
>>> +
>>> +Required properties:
>>> +  - compatible: "led-backlight"
>>> +  - leds: phandle to a led OF node [0]
>>
>> Why do we need 2 levels of LED nodes?
>
> Sorry, didn't get that. What do you mean with 2 levels?

You have the node the "leds" phandle points to which is the actual LED
device and then this node which is just backlight properties. And then
presumably another phandle in the panel device to point to the
backlight device.

>>> +  - brightness-levels: Array of distinct LED brightness levels. These
>>> +  are in the range from 0 to 255, passed to the LED class driver.
>>> +  - default-brightness-level: the default brightness level (index into the
>>> +  array defined by the "brightness-levels" property)
>>> +
>>> +Optional properties:
>>> +  - power-supply: regulator for supply voltage
>>> +  - enable-gpios: contains a single GPIO specifier for the GPIO which 
>>> enables
>>> +  and disables the backlight (see GPIO binding[1])
>>
>> Why are all of these not part of the LED node pointed to by leds?
>
> These are for the backlight, not for the LED chip. So "LED" here is a
> chip that produces (most likely) a PWM signal, and "backlight" is the
> collection of components that use the PWM to produce the backlight
> itself, and use the power-supply and gpios.

Okay, it wasn't clear that leds points to the LED controller node. The
example made it seem as it was the device. We already have a way to
describe LEDs and that is as child nodes of the LED controller node.
Please follow what was done for flash LEDs (leds/common.txt).

What's wrong with the existing pwm-backlight binding in the PWM case?

>
>> Describe the h/w, not what you want for a driver.
>
> I think this describes the HW quite well. The LED chip works fine
> without any of the properties here, and these are specific to the
> backlight part of the board.

A more complete example would be helpful here.

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

[PATCH 08/13] clk: add ARM syscon ICST device tree bindings

[Linus Walleij]

This adds the device tree bindings for the ARM Syscon ICST
oscillators, which is a register-level interface to the
Integrated Device Technology (IDT) ICS525 and ICS307
serially programmable oscillators.

Cc: devicetree@vger.kernel.org
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: linux-...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
I'm looking for an ACK from the CLK maintainers to take this
through the ARM SoC tree once the series stabilize.
---
 .../devicetree/bindings/clock/arm-syscon-icst.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/arm-syscon-icst.txt

diff --git a/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt 
b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
new file mode 100644
index ..19eb3aa765c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
@@ -0,0 +1,40 @@
+ARM System Controller ICST clocks
+
+The ICS525 and ICS307 oscillators are produced by Integrated Devices
+Technology (IDT). ARM integrated these oscillators deeply into their
+reference designs by adding special control registers that manage such
+oscillators to their system controllers.
+
+The ARM system controller contains logic to serialized and initialize
+an ICST clock request after a write to the 32 bit register at an offset
+into the system controller. Further, to even be able to alter one of
+these frequencies, the system controller must first be unlocked by
+writing a special token to another offset in the system controller.
+
+The ICST oscillator must be provided inside a system controller node.
+
+Required properties:
+- lock-offset: the offset address into the system controller where the
+  unlocking register is located
+- vco-offset: the offset address into the system controller where the
+  ICST control register is located (even 32 bit address)
+- compatible: must be one of "arm,syscon-icst525" or "arm,syscon-icst307"
+- #clock-cells: must be <0>
+- clocks: parent clock, since the ICST needs a parent clock to derive its
+  frequency from, this attribute is compulsory.
+
+Example:
+
+syscon: syscon@1000 {
+   compatible = "syscon";
+   reg = <0x1000 0x1000>;
+
+   oscclk0: osc0@0c {
+   compatible = "arm,syscon-icst307";
+   #clock-cells = <0>;
+   lock-offset = <0x20>;
+   vco-offset = <0x0C>;
+   clocks = <>;
+   };
+   (...)
+};
-- 
2.4.3

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

[PATCH 03/13] irqchips: fix ARM11MPCore GIC bindings

[Linus Walleij]

The GIC bindings for the ARM11MPCore need to differentiate between
the GIC on the Test Chip and the one on the evaluation baseboard.
Split the binding in two and define new compatible-strings.

Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij 
---
 Documentation/devicetree/bindings/arm/gic.txt | 3 ++-
 drivers/irqchip/irq-gic.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
b/Documentation/devicetree/bindings/arm/gic.txt
index 2da059a4790c..a5445622c216 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -15,7 +15,8 @@ Main node required properties:
"arm,cortex-a15-gic"
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
-   "arm,arm11mp-gic"
+   "arm,tc11mp-gic"
+   "arm,pb11mp-gic"
"brcm,brahma-b15-gic"
"arm,arm1176jzf-devchip-gic"
"qcom,msm-8660-qgic"
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 982c09c2d791..5376d1cb0a4f 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1184,7 +1184,8 @@ gic_of_init(struct device_node *node, struct device_node 
*parent)
return 0;
 }
 IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
-IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init);
+IRQCHIP_DECLARE(armtc11mp_gic, "arm,tc11mp-gic", gic_of_init);
+IRQCHIP_DECLARE(armpb11mp_gic, "arm,pb11mp-gic", gic_of_init);
 IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init);
 IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
 IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
-- 
2.4.3

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

[PATCH 2/2] pinctrl: sunxi: Add irq pinmuxing to sun6i "r" pincontroller

[Hans de Goede]

Add pinmuxing for external interrupt functionality through the
sun6i "r" pincontroller.

Signed-off-by: Hans de Goede 
---
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c 
b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
index 9596b0a3..88bd20f 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
@@ -47,45 +47,57 @@ static const struct sunxi_desc_pin sun6i_a31_r_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 0, 0),   /* PL_EINT0 */
  SUNXI_FUNCTION(0x3, "s_jtag")),   /* MS */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 0, 1),   /* PL_EINT1 */
  SUNXI_FUNCTION(0x3, "s_jtag")),   /* CK */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 0, 2),   /* PL_EINT2 */
  SUNXI_FUNCTION(0x3, "s_jtag")),   /* DO */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 0, 3),   /* PL_EINT3 */
  SUNXI_FUNCTION(0x3, "s_jtag")),   /* DI */
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 0),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 0),   /* PM_EINT0 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 1),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 1),   /* PM_EINT1 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 2),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 2),   /* PM_EINT2 */
  SUNXI_FUNCTION(0x3, "1wire")),
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 3),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 3),   /* PM_EINT3 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 4),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 4),   /* PM_EINT4 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 5),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 5),   /* PM_EINT5 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 6),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 6),   /* PM_EINT6 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(M, 7),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_IRQ_BANK(0x2, 1, 7),   /* PM_EINT7 */
  SUNXI_FUNCTION(0x3, "rtc")),  /* CLKO */
 };
 
-- 
2.5.0

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

[PATCH] ARM: keystone: dts: add PCI serdes driver bindings

[WingMan Kwok]

This patch adds the required PCI serdes bindings whcih can then be
enabled by setting the corresponding statuses to "ok" in order to
configure and start the PCI serdes.

This patch depends on the updates to the Keystone PCIe host driver
and common serdes driver patch series that is submitted separately.

Signed-off-by: WingMan Kwok 
---
 arch/arm/boot/dts/k2e.dtsi  |   21 +
 arch/arm/boot/dts/keystone.dtsi |   21 +
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 675fb8e..3b36575 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -86,6 +86,16 @@
gpio,syscon-dev = < 0x240>;
};
 
+   pcie1_phy: pciephy@2326000 {
+   #phy-cells = <0>;
+   compatible = "ti,keystone-serdes-pcie";
+   reg = <0x02326000 0x4000>;
+   reg-names = "serdes";
+   link-rate-kbps = <500>;
+   num-lanes = <2>;
+   status = "disabled";
+   };
+
pcie1: pcie@2102 {
compatible = "ti,keystone-pcie","snps,dw-pcie";
clocks = <>;
@@ -130,6 +140,17 @@
,
;
};
+
+   /* PCIE phy */
+   serdeses {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   serdes@0 {
+   reg = <0>;
+   phys = <_phy>;
+   };
+   };
+
};
 
mdio: mdio@24200f00 {
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 72816d6..6566cc4 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -275,6 +275,16 @@
ti,syscon-dev = < 0x2a0>;
};
 
+   pcie0_phy: pciephy@232 {
+   #phy-cells = <0>;
+   compatible = "ti,keystone-serdes-pcie";
+   reg = <0x0232 0x4000>;
+   reg-names = "serdes";
+   link-rate-kbps = <500>;
+   num-lanes = <2>;
+   status = "disabled";
+   };
+
pcie0: pcie@2180 {
compatible = "ti,keystone-pcie", "snps,dw-pcie";
clocks = <>;
@@ -319,6 +329,17 @@
,
;
};
+
+   /* PCIE phy */
+   serdeses {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   serdes@0 {
+   reg = <0>;
+   phys = <_phy>;
+   };
+   };
+
};
};
 };
-- 
1.7.9.5

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

[PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[WingMan Kwok]

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

v1:
- see cover letter for review comments addressed.

Signed-off-by: WingMan Kwok 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
 drivers/phy/Kconfig  |8 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-keystone-serdes.c| 2373 ++
 4 files changed, 2660 insertions(+)
 create mode 100644 drivers/phy/phy-keystone-serdes.c

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9cf9446..4dca271 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -115,4 +115,282 @@ sata_phy: phy@4A096000 {
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
#phy-cells = <0>;
+
+TI Keystone SerDes PHY
+==
+
+Required properties:
+ - compatible: should be one of
+   * "ti,keystone-serdes-gbe"
+   * "ti,keystone-serdes-xgbe"
+   * "ti,keystone-serdes-pcie"
+ - reg:
+   * base address and length of the SerDes register set
+ - reg-names:
+   * "serdes"
+   - name of the reg SerDes register set
+ - #phy-cells:
+   * From the generic phy bindings, must be 0;
+ - num-lanes:
+   * Number of lanes in SerDes.
+
+Optional properties:
+ - syscon-peripheral:
+   * Handle to the subsystem register region of the peripheral
+ inside which the SerDes exists.
+ - syscon-link:
+   * Handle to the Link register region of the peripheral inside
+ which the SerDes exists.  Example: it is the PCSR register
+ region in the case of 10gbe.
+ - rx-force-enable:
+   * Include this property if receiver attenuation and boost are
+ to be configured with specific values defined in rx-force.
+ - link-rate-kbps:
+   * SerDes link rate to be configured, in kbps.
+
+
+For gbe and 10gbe SerDes, it is optional to represent each lane as
+a sub-node, which can be enabled or disabled individually using
+the "status" property.
+
+Required properties (lane sub-node):
+ - reg:
+   * lane number
+
+Optional properties (lane sub-node):
+ - control-rate:
+   * Lane control rate
+   0: full rate
+   1: half rate
+   2: quarter rate
+ - rx-start:
+   * Initial lane rx equalizer attenuation and boost configurations.
+   * Must be array of 2 integers.
+ - rx-force:
+   * Forced lane rx equalizer attenuation and boost configurations.
+   * Must be array of 2 integers.
+ - tx-coeff:
+   * Lane c1, c2, cm, attenuation and regulator output voltage
+ configurations.
+   * Must be array of 5 integers.
+ - loopback:
+   * Include this property to enable loopback at the SerDes
+ lane level.
+
+Example for Keystone K2E GBE:
+-
+
+gbe_serdes0: gbe_serdes@232a000 {
+   #phy-cells  = <0>;
+   compatible  = "ti,keystone-serdes-gbe";
+   reg = <0x0232a000 0x2000>;
+   reg-names   = "serdes";
+   link-rate-kbps  = <125>;
+   num-lanes   = <4>;
+   lanes {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lane@0 {
+   /*loopback;*/
+   reg = <0>;
+   control-rate= <2>; /* quart */
+   rx-start= <7 5>;
+   rx-force= <1 1>;
+   tx-coeff= <0 0 0 12 4>;
+  /* c1 c2 cm att vreg */
+   };
+   lane@1 {
+   /*loopback;*/
+   reg = <1>;
+   control-rate= <2>; /* quart */
+   rx-start= <7 5>;
+   rx-force= <1 1>;
+   tx-coeff= <0 0 0 12 4>;
+  /* c1 c2 cm att vreg */
+   };
+   };
+};
+
+gbe_serdes1: gbe_serdes@2324000 {
+   #phy-cells  = <0>;
+   compatible  = "ti,keystone-serdes-gbe";
+   reg = <0x02324000 0x2000>;
+   reg-names 

[PATCH 0/2] pinctrl: sunxi: r_pio pinctrl irq fixes

[Hans de Goede]

Hi Linus, Maxime,

Here are some fixes for supporting external interrupts connected to
the "r" (extra) pincontroller found on newer sunxi SoCs.

This series has been tested on a BPI-M2 which has the sdio OOB irq
hooked up to PL5, with this series applied the OOB irq works as it
should.

Regards,

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

[PATCH 1/2] pinctrl: sunxi: Fix irq_of_xlate for the r_pio pinctrl block

[Hans de Goede]

The r_pio gpio / pin controller has a pin_base of non 0, we need to
adjust for this before calling sunxi_pinctrl_desc_find_function_by_pin.

Signed-off-by: Hans de Goede 
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 38e0c7b..96a58e4 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -716,6 +716,7 @@ static int sunxi_pinctrl_irq_of_xlate(struct irq_domain *d,
  unsigned long *out_hwirq,
  unsigned int *out_type)
 {
+   struct sunxi_pinctrl *pctl = d->host_data;
struct sunxi_desc_function *desc;
int pin, base;
 
@@ -723,10 +724,9 @@ static int sunxi_pinctrl_irq_of_xlate(struct irq_domain *d,
return -EINVAL;
 
base = PINS_PER_BANK * intspec[0];
-   pin = base + intspec[1];
+   pin = pctl->desc->pin_base + base + intspec[1];
 
-   desc = sunxi_pinctrl_desc_find_function_by_pin(d->host_data,
-  pin, "irq");
+   desc = sunxi_pinctrl_desc_find_function_by_pin(pctl, pin, "irq");
if (!desc)
return -EINVAL;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Graham Moore]

On 08/21/2015 04:20 AM, Marek Vasut wrote:

From: Graham Moore 

Add support for the Cadence QSPI controller. This controller is
present in the Altera SoCFPGA SoCs and this driver has been tested
on the Cyclone V SoC.

Signed-off-by: Graham Moore 
Signed-off-by: Marek Vasut 


[...]

Hi, just checking in.  Are there any more changes to this driver?

Best Regards,
Graham

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

[PATCH v1 2/2] PCI: keystone: update to use generic keystone serdes driver

[WingMan Kwok]

This patch updates the Keystone PCI driver to use the
generic Keystone serdes driver for serdes initialization
and configuration.  The generic serdes driver supports
peripherals on Keystone platforms that require serdes.

v1:
- no change.

Signed-off-by: WingMan Kwok 
---
 drivers/pci/host/pci-keystone.c |   54 ---
 drivers/pci/host/pci-keystone.h |2 ++
 2 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd..b4de05b 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -335,6 +335,7 @@ static int __exit ks_pcie_remove(struct platform_device 
*pdev)
 {
struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
 
+   phy_exit(ks_pcie->serdes_phy);
clk_disable_unprepare(ks_pcie->clk);
 
return 0;
@@ -342,6 +343,8 @@ static int __exit ks_pcie_remove(struct platform_device 
*pdev)
 
 static int __init ks_pcie_probe(struct platform_device *pdev)
 {
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *serdeses_np, *child;
struct device *dev = >dev;
struct keystone_pcie *ks_pcie;
struct pcie_port *pp;
@@ -349,6 +352,7 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
void __iomem *reg_p;
struct phy *phy;
int ret = 0;
+   u32 phy_num;
 
ks_pcie = devm_kzalloc(>dev, sizeof(*ks_pcie),
GFP_KERNEL);
@@ -357,14 +361,6 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
 
pp = _pcie->pp;
 
-   /* initialize SerDes Phy if present */
-   phy = devm_phy_get(dev, "pcie-phy");
-   if (!IS_ERR_OR_NULL(phy)) {
-   ret = phy_init(phy);
-   if (ret < 0)
-   return ret;
-   }
-
/* index 2 is to read PCI DEVICE_ID */
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
reg_p = devm_ioremap_resource(dev, res);
@@ -385,6 +381,46 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   serdeses_np = of_get_child_by_name(node, "serdeses");
+   if (serdeses_np) {
+   for_each_available_child_of_node(serdeses_np, child) {
+   ret = of_property_read_u32(child, "reg", _num);
+   if (ret) {
+   dev_err(dev, "Failed to parse device tree\n");
+   of_node_put(child);
+   of_node_put(serdeses_np);
+   goto fail_clk;
+   }
+
+   if (phy_num >= MAX_NUM_PCI_SERDES) {
+   dev_err(dev, "Invalid phy number: %u\n",
+   phy_num);
+   of_node_put(child);
+   of_node_put(serdeses_np);
+   ret = -EINVAL;
+   goto fail_clk;
+   }
+
+   phy = devm_of_phy_get(dev, child, NULL);
+   of_node_put(child);
+   ks_pcie->serdes_phy = phy;
+   if (IS_ERR(phy)) {
+   dev_err(dev, "No %s serdes driver found: %ld\n",
+   node->name, PTR_ERR(phy));
+   of_node_put(serdeses_np);
+   ret = PTR_ERR(phy);
+   goto fail_clk;
+   }
+
+   ret = phy_init(phy);
+   if (ret < 0) {
+   of_node_put(serdeses_np);
+   goto fail_clk;
+   }
+   }
+   of_node_put(serdeses_np);
+   }
+
ret = ks_add_pcie_port(ks_pcie, pdev);
if (ret < 0)
goto fail_clk;
@@ -392,7 +428,7 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
return 0;
 fail_clk:
clk_disable_unprepare(ks_pcie->clk);
-
+   phy_exit(ks_pcie->serdes_phy);
return ret;
 }
 
diff --git a/drivers/pci/host/pci-keystone.h b/drivers/pci/host/pci-keystone.h
index 478d932..21662ba 100644
--- a/drivers/pci/host/pci-keystone.h
+++ b/drivers/pci/host/pci-keystone.h
@@ -15,6 +15,7 @@
 #define MAX_LEGACY_IRQS4
 #define MAX_MSI_HOST_IRQS  8
 #define MAX_LEGACY_HOST_IRQS   4
+#define MAX_NUM_PCI_SERDES 1
 
 struct keystone_pcie {
struct  clk *clk;
@@ -33,6 +34,7 @@ struct keystone_pcie {
/* Application register space */
void __iomem*va_app_base;
struct resource app;
+   struct phy  *serdes_phy;
 };
 
 /* Keystone DW specific MSI controller 

[PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms

[WingMan Kwok]

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethether switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch series provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

As an example of the using the SerDes driver, this patch series also
updates the Keystone PCIe host driver to enable and use its SerDes block.

References:
[1] KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide
(http://www.ti.com/lit/ug/spruho3a/spruho3a.pdf)

v1: 
- addresses the following review comments
1. https://lkml.org/lkml/2015/10/13/803
2. https://lkml.org/lkml/2015/10/14/613
3. https://lkml.org/lkml/2015/10/13/818

- An update to PCIe dts bindings to enable the PCIe SerDes is
  submitted in a separate patch.

WingMan Kwok (2):
  phy: keystone: serdes driver for gbe 10gbe and pcie
  PCI: keystone: update to use generic keystone serdes driver

 Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
 drivers/pci/host/pci-keystone.c  |   54 +-
 drivers/pci/host/pci-keystone.h  |2 +
 drivers/phy/Kconfig  |8 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-keystone-serdes.c| 2373 ++
 6 files changed, 2707 insertions(+), 9 deletions(-)
 create mode 100644 drivers/phy/phy-keystone-serdes.c

-- 
1.7.9.5

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

Re: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller

[Mathias Nyman]

On 29.09.2015 06:01, Chunfeng Yun wrote:

There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
   to minimize the scheduling effort for synchronous and
   interrupt endpoints. The parameters are put into reseved
   DWs of slot context and endpoint context.
2. Its IMODI unit for Interrupter Moderation register is
   8 times as much as that defined in xHCI spec.
3. Its TDS in  Normal TRB defines a number of packets that
   remains to be transferred for a TD after processing all
   Max packets in all previous TRBs.

Signed-off-by: Chunfeng Yun 


Looks good in my opinion, There's one part about how we split the ISOC 
transafers
across multiple microframes that I don't fully understand:


+   } else if (udev->speed == USB_SPEED_SUPER) {
+   /* usb3_r1 spec section4.4.7 & 4.4.8 */
+   sch_ep->cs_count = 0;
+   esit_pkts = (mult + 1) * (max_burst + 1);


So the device would like the transfers to be esit_pkts packets every esit 
microframe apart.


+   if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
+   sch_ep->pkts = esit_pkts;
+   sch_ep->num_budget_microframes = 1;
+   sch_ep->repeat = 0;
+   }
+
+   if (ep_type == ISOC_IN_EP || ep_type == ISOC_OUT_EP) {
+   if (esit_pkts <= sch_ep->esit)
+   sch_ep->pkts = 1;
+   else
+   sch_ep->pkts = roundup_pow_of_two(esit_pkts)
+   / sch_ep->esit;


sch_ep->pkts now contain a rounded up average value of how many packets per 
microframe
would be transferred in case we'd transfer packets every microframe instead of 
every esit frame apart.


+
+   sch_ep->num_budget_microframes =
+   DIV_ROUND_UP(esit_pkts, sch_ep->pkts);


sch_ep->num_budget_microframes now contains the number of microframes during an 
esit needed
to transer all data if each microframe contains the average amount of data.

So basically we are trying to use as many microframes as possible with as few 
packets
per microframe as possible.

Did I understand this correctly?
How will devices react if they expect to get 16 packets every 16th microframe,
but they get one packet every microframe instead?

Or is this just theoretical bw calculations for the host and it will in the end 
do
whatever it wants with the information.

Otherwise, by making the changes Daniel Thompson suggested I think the xhci 
parts looks ready.

-Mathias

 

  
 



















+   } else if (is_fs_or_ls(udev->speed)) {
+
+   /*
+* usb_20 spec section11.18.4
+* assume worst cases
+*/
+   sch_ep->repeat = 0;
+   sch_ep->pkts = 1; /* at most one packet for each microframe */
+   if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
+   sch_ep->cs_count = 3; /* at most need 3 CS*/
+   /* one for SS and one for budgeted transaction */
+   sch_ep->num_budget_microframes = sch_ep->cs_count + 2;
+   sch_ep->bw_cost_per_microframe = max_packet_size;
+   }
+   if (ep_type == ISOC_OUT_EP) {
+
+   /*
+* the best case FS budget assumes that 188 FS bytes
+* occur in each microframe
+*/
+   sch_ep->num_budget_microframes = DIV_ROUND_UP(
+   max_packet_size, FS_PAYLOAD_MAX);
+   sch_ep->bw_cost_per_microframe = FS_PAYLOAD_MAX;
+   sch_ep->cs_count = sch_ep->num_budget_microframes;
+   }
+   if (ep_type == ISOC_IN_EP) {
+   /* at most need additional two CS. */
+   sch_ep->cs_count = DIV_ROUND_UP(
+   max_packet_size, FS_PAYLOAD_MAX) + 2;
+   sch_ep->num_budget_microframes = sch_ep->cs_count + 2;
+   sch_ep->bw_cost_per_microframe = FS_PAYLOAD_MAX;
+   }
+   }
+}
+
+/* Get maximum bandwidth when we schedule at offset slot. */
+static u32 get_max_bw(struct mu3h_sch_bw_info *sch_bw,
+   struct mu3h_sch_ep_info *sch_ep, u32 offset)
+{
+   u32 num_esit;
+   u32 max_bw = 0;
+   int i;
+   int j;
+
+   num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
+   for (i = 0; i < num_esit; i++) {
+   u32 base = offset + i * sch_ep->esit;
+
+   for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+   if (sch_bw->bus_bw[base + j] > max_bw)
+   max_bw = sch_bw->bus_bw[base + j];
+   }
+   }
+   return max_bw;
+}
+
+static void 

Re: [PATCH v2 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files

[Jon Mason]

On Thu, Oct 15, 2015 at 10:55:16PM +0200, Hauke Mehrtens wrote:
> On 10/15/2015 10:40 PM, Hauke Mehrtens wrote:
> > On 10/15/2015 12:14 AM, Jon Mason wrote:
> >> Add device tree files for Broadcom Northstar based SVKs.  Since the
> >> bcm5301x.dtsi already exists, all that is necessary is the dts files to
> >> enable the UARTs (and specify the RAM size for the 4708/9).  With these
> >> files, the SVKs are able to boot to shell.
> 
> One additional question. What flash are you using on these boards? For
> some common NAND flash properties you only have to include
> bcm5301x-nand-cs0-bch8.dtsi or do these boards use serial or parallel flash?

To be honest, I haven't gotten far enough to investigate that.  I am
assuming that it is "brcm,nand-iproc" like NSP (which is different
than the file you reference).  

Thanks,
Jon

> 
> Hauke
> 
> >>
> >> Signed-off-by: Jon Mason 
> >> ---
> >>  arch/arm/boot/dts/Makefile   |  5 +++-
> >>  arch/arm/boot/dts/bcm94708.dts   | 56 +++
> >>  arch/arm/boot/dts/bcm94709.dts   | 56 +++
> >>  arch/arm/boot/dts/bcm953012k.dts | 63 
> >> 
> >>  4 files changed, 179 insertions(+), 1 deletion(-)
> >>  create mode 100644 arch/arm/boot/dts/bcm94708.dts
> >>  create mode 100644 arch/arm/boot/dts/bcm94709.dts
> >>  create mode 100644 arch/arm/boot/dts/bcm953012k.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 233159d..96a1b58 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
> >>bcm47081-buffalo-wzr-900dhp.dtb \
> >>bcm4709-asus-rt-ac87u.dtb \
> >>bcm4709-buffalo-wxr-1900dhp.dtb \
> >> -  bcm4709-netgear-r8000.dtb
> >> +  bcm4709-netgear-r8000.dtb \
> >> +  bcm94708.dtb \
> >> +  bcm94709.dtb \
> >> +  bcm953012k.dtb
> >>  dtb-$(CONFIG_ARCH_BCM_63XX) += \
> >>bcm963138dvt.dtb
> >>  dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
> >> diff --git a/arch/arm/boot/dts/bcm94708.dts 
> >> b/arch/arm/boot/dts/bcm94708.dts
> >> new file mode 100644
> >> index 000..f60bb1d
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/bcm94708.dts
> >> @@ -0,0 +1,56 @@
> >> +/*
> >> + *  BSD LICENSE
> >> + *
> >> + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
> >> + *
> >> + *  Redistribution and use in source and binary forms, with or without
> >> + *  modification, are permitted provided that the following conditions
> >> + *  are met:
> >> + *
> >> + ** Redistributions of source code must retain the above copyright
> >> + *  notice, this list of conditions and the following disclaimer.
> >> + ** Redistributions in binary form must reproduce the above copyright
> >> + *  notice, this list of conditions and the following disclaimer in
> >> + *  the documentation and/or other materials provided with the
> >> + *  distribution.
> >> + ** Neither the name of Broadcom Corporation nor the names of its
> >> + *  contributors may be used to endorse or promote products derived
> >> + *  from this software without specific prior written permission.
> >> + *
> >> + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >> + *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> >> + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> >> + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> >> + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> >> + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >> + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> >> + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> >> + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> >> + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> >> + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "bcm5301x.dtsi"
> > 
> > Please include bcm4708.dtsi instead here.
> > 
> >> +
> >> +/ {
> >> +  model = "NorthStar SVK (BCM94708)";
> >> +  compatible = "brcm,bcm94708", "brcm,bcm4708";
> >> +
> >> +  aliases {
> >> +  serial0 = 
> >> +  };
> >> +
> >> +  chosen {
> >> +  bootargs = "console=ttyS0,115200";
> >> +  };
> >> +
> >> +  memory {
> >> +  reg = <0x 0x0800>;
> >> +  };
> >> +};
> >> +
> >> + {
> >> +  status = "okay";
> >> +};
> >> diff --git a/arch/arm/boot/dts/bcm94709.dts 
> >> b/arch/arm/boot/dts/bcm94709.dts
> >> new file mode 100644
> >> index 000..88de313
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/bcm94709.dts
> >> @@ -0,0 +1,56 @@
> >> +/*
> >> + *  BSD LICENSE
> >> + *
> >> + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
> >> + *
> >> + *  Redistribution 

Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

On 15-10-15 02:15 PM, Ray Jui wrote:



On 10/15/2015 2:10 PM, Jon Mason wrote:

On Thu, Oct 15, 2015 at 02:04:09PM -0700, Scott Branden wrote:

Hi Ray,

Comment at near end.

On 15-10-15 01:55 PM, Ray Jui wrote:



On 10/15/2015 1:40 PM, Scott Branden wrote:

We need some sort of kconfig option to differentiate NS2 clock driver

>from being pulled in all the time.


On 15-10-15 12:48 PM, Jon Mason wrote:

The Broadcom Northstar 2 SoC is architected under the iProc
architecture. It has the following PLLs: GENPLL SCR, GENPLL SW,
LCPLL DDR, LCPLL Ports, all derived from an onboard crystal.

Signed-off-by: Jon Mason 
---
   drivers/clk/Makefile|   2 +-
   drivers/clk/bcm/Makefile|   1 +
   drivers/clk/bcm/clk-ns2.c   | 288

   include/dt-bindings/clock/bcm-ns2.h |  72 +
   4 files changed, 362 insertions(+), 1 deletion(-)
   create mode 100644 drivers/clk/bcm/clk-ns2.c
   create mode 100644 include/dt-bindings/clock/bcm-ns2.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5..6124bd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
   obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
   obj-$(CONFIG_COMMON_CLK_PWM)+= clk-pwm.o
   obj-$(CONFIG_COMMON_CLK_AT91)+= at91/
-obj-$(CONFIG_ARCH_BCM)+= bcm/
+obj-y+= bcm/
   obj-$(CONFIG_ARCH_BERLIN)+= berlin/
   obj-$(CONFIG_ARCH_HISI)+= hisilicon/
   obj-$(CONFIG_ARCH_MXC)+= imx/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index e258b28..2d1cbc5 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_CLK_BCM_KONA)+= clk-kona-setup.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
   obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o
clk-iproc-pll.o clk-iproc-asiu.o
+obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-ns2.o


NS2 code is dragged in for all IPROC SoCs.  We need a config option for
NS2 (CONFIG_ARCH_BCM_NS2) to avoid this (if Arnd allows this for ARMv8
processors... ?).

You can see below ARMv7 processors don't have this problem.



The arm64 maintainers (Catalin, Mark, and etc.) stated they only want
one ARCH options per chip family.


If not we need to add CONFIG_CLK_NS2.


If using CONFIG_CLK_NS2, how is it going to be enabled/selected?


Since CONFIG_ARCH_BCM_NS2 isn't "allowed" to be introduced we will
need to create and select a CONFIG_CLK_BCM_NS2 in the defconfig
instead.


Is this better than the binary becoming slightly bigger?  I thought
the extra complexity was worse than having an unused chunk of clk code
(and Kona is already doing the same thing above).  I believe Ray was
in agreement with me during the internal review of this code.

Thanks,
Jon



Yes, I'm okay with leaving it as it is. I even prefer changing the
current Makefile to make all iProc based core clock drivers and SoC
specific clock tables under CONFIG_COMMON_CLK_IPROC, which is what some
of the other vendors do.

I'd leave it exactly as is then rather than pulling in more dead code 
when not needed.  This ns2 clock code is very minor compared to other 
code bloat in the kernel and drivers.


Ray



Regards,
  Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] clk: samsung: exynos5250: Add DISP1 clocks

[Krzysztof Kozlowski]

On 15.10.2015 19:31, Tomeu Vizoso wrote:
> When the DISP1 power domain is powered off, there's two clocks that need
> to be temporarily reparented to OSC, and back to their original parents
> when the domain is powered on again.
> 
> We expose these two clocks in the DT bindings so that the DT node of the
> power domain can reference them.
> 
> Signed-off-by: Tomeu Vizoso 
> Acked-by: Stephen Boyd 
> ---
> 
> Changes in v2:
> - Reuse mout_aclk200_p
> - Rename div_aclk300 as div_aclk300_disp
> 
>  drivers/clk/samsung/clk-exynos5250.c   | 14 +-
>  include/dt-bindings/clock/exynos5250.h |  4 +++-
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


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

RE: [PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms

[Kwok, WingMan]

Hello,

> -Original Message-
> From: KISHON VIJAY ABRAHAM
> Sent: Thursday, October 15, 2015 3:22 PM
> To: Russell King - ARM Linux; Kwok, WingMan
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Quadros, Roger;
> Karicheri, Muralidharan; bhelg...@google.com; ssant...@kernel.org;
> devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms
> 
> Hi,
> 
> On Thursday 15 October 2015 10:21 PM, Russell King - ARM Linux wrote:
> > On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
> >> On TI's Keystone platforms, several peripherals such as the
> >> gbe ethernet switch, 10gbe ethether switch and PCIe controller
> >> require the use of a SerDes for converting SoC parallel data into
> >> serialized data that can be output over a high-speed electrical
> >> interface, and also converting high-speed serial input data
> >> into parallel data that can be processed by the SoC.  The
> >> SerDeses used by those peripherals, though they may be different,
> >> are largely similar in functionality and setup.
> >
> > Given that serdes is not specific to TI, should this be specific to
> > TI, or should there be an effort to come up with something which
> > everyone who has serdes links can make use of?
> >
> > Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
> > 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
> > plethora of SoC specific stuff for this.
> 
> Generally every SoC use it's own serdes and the programming required is
> different for different SoCs. Each of them have their own register map
> and clock programming/regulator programming/reset programming are all
> different.
> 
> However most SoC vendors use the same PHY/SerDes IP to be used by
> multiple controllers like PCIe/SATA/USB in a single SoC and a single PHY
> driver is used for programming all these PHYs.
> 

Thanks so much for the clarifications.

> Thanks
> Kishon
> 

Regards,
WingMan

> >
> > When serdes is combined with SFP cages, the situation becomes much
> > more fun, because the serdes link then needs to become hotpluggable
> > (SFP modules are designed to be hotplugged) which means you have to
> > be able to switch between (at least) 1G SGMII and 1000base-X modes,
> > and probably 10G mode as well.  There's even a SFP module that has
> > a SATA connector on it, though I believe there's no standard for
> > that, and it's more a hardware hack.
> >
> > I've been working in this area but from the Ethernet side on an
> > Armada 38x based board which has a SFP cage on it, though it's
> > slightly simpler there because there is no support (or I believe
> > any desire) to reconfigure the serdes lanes between PCI, ethernet
> > and SATA - that's all setup and initialised for us by uboot.
> >

Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding

[Stephen Boyd]

On 09/14, Rob Herring wrote:
> On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> > Regulators already have stable DT bindings, wherein the consumer (of
> > supplies) will have following for each regulator/supply.
> > 
> > -supply: ;
> > 
> > Current OPP bindings extend above, by transforming it into a list of
> > phandles. But we missed the  string, which is used to identify the
> > regulator.
> > 
> > And looking from regulators perspective, having two different ways of
> > specifying regulators doesn't seem like a step forward, it also means we
> > have to update every single device binding. And things will become
> > complex.
> > 
> > Another way to support multiple regulators per device (in OPP V2
> > bindings) is to leave regulator consumer bindings as is, and create a
> > 'supply-names' property in the opp-table node, which will contain a list
> > of strings. The names in this list shall match 'name' from the
> > '-supply' strings present in the device node.
> > 
> > The strings in this list also specify the order in which values must be
> > present in 'opp-microvolt' and 'opp-microamp' properties.
> > 
> > Cc: Mark Brown 
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Viresh Kumar 
> > ---
> >  Documentation/devicetree/bindings/opp/opp.txt | 26 
> > +++---
> >  1 file changed, 19 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
> > b/Documentation/devicetree/bindings/opp/opp.txt
> > index 0cb44dc21f97..8759bc4783ed 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -69,6 +69,13 @@ This describes the OPPs belonging to a device. This node 
> > can have following
> >  - compatible: Allow OPPs to express their compatibility. It should be:
> >"operating-points-v2".
> >  
> > +- supply-names: This is a required property, only if multiple supplies are
> > +  available for the device. Otherwise it is optional.
> > +
> > +  This list is used to pass names of all the device supplies. The order of 
> > names
> > +  present here is important, as that should match the order in which 
> > values are
> > +  present in 'opp-microvolt' and 'opp-microamp' properties.
> > +
> 
> What if we have a 2nd device and supply rail? For example, what if the
> L2$ has a separate rail from the cores but is linked to the OPPs.

I'm lost why we need this property at all. What happened to using

 opp-microvolt-0 = <1 2 3>;
 opp-microvolt-1 = <1>;
 opp-microvolt-2 = <3 4 5>;
 etc.

That seems to avoid any problem with 3 vs. 1 element properties
combined into one large array. Having supply-names seems too
brittle and would tie us to a particular OPP user's decision to
call supplies by some name.

Also, I've seen devices that are split across two power domains.
These devices aren't CPUs, but they are other devices including
L2 caches. So we're going to need either multiple regulator
support or multiple "power domain at a particular performance
levels" support somehow.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] powerpc/dts: Add DT alias for Freescale eSPI controller

[Hou Zhiqiang]

Hi Rob,

Could you please help to apply this patch due to no comments from community?
Thanks a lot!

Thanks,
Zhiqiang

> -Original Message-
> From: Hou Zhiqiang-B48286
> Sent: 2015年9月28日 11:02
> To: Hou Zhiqiang-B48286; devicetree@vger.kernel.org; ga...@codeaurora.org;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk
> Cc: Hu Mingkai-B21284
> Subject: RE: [PATCH] powerpc/dts: Add DT alias for Freescale eSPI
> controller
> 
> Hi Rob,
> 
> Could you please help to apply this patch, no comment for a month.
> 
> Thanks,
> Zhiqiang
> 
> > -Original Message-
> > From: Hou Zhiqiang-B48286
> > Sent: 2015年9月15日 15:51
> > To: Hou Zhiqiang-B48286; devicetree@vger.kernel.org;
> > ga...@codeaurora.org;
> > robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> > ijc+devicet...@hellion.org.uk
> > Cc: Hu Mingkai-B21284
> > Subject: RE: [PATCH] powerpc/dts: Add DT alias for Freescale eSPI
> > controller
> >
> > Hi,
> >
> > Any response, please comment.
> >
> > > -Original Message-
> > > From: Zhiqiang Hou [mailto:b48...@freescale.com]
> > > Sent: 2015年8月19日 19:55
> > > To: devicetree@vger.kernel.org; ga...@codeaurora.org;
> > > robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> > > ijc+devicet...@hellion.org.uk
> > > Cc: Hu Mingkai-B21284; Hou Zhiqiang-B48286
> > > Subject: [PATCH] powerpc/dts: Add DT alias for Freescale eSPI
> > > controller
> > >
> > > From: Hou Zhiqiang 
> > >
> > > Add aliases for eSPI device node to assign the alias id to the bus
> > > number of spi_master.
> > >
> > > For the platforms used the device tree, the bus numbers are
> > > dynamically assigned and are not predictable. However, sometimes it
> > > must be figured out, e.g. using mtdparts in cmdline to specify the
> > layout of spi flash.
> > >
> > > Signed-off-by: Hou Zhiqiang 
> > > ---
> > >  arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/b4si-post.dtsi  | 2 +-
> > >  arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 2 +-
> > > arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi  | 1 +
> > >  arch/powerpc/boot/dts/fsl/p1020si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p1021si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p1022si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p1023si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p2041si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p3041si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p4080si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p5020si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/p5040si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/t1023si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/t1040si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/t2081si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi| 1 +
> > >  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi   | 2 +-
> > >  arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi| 1 +
> > >  31 files changed, 31 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> > > b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> > > index 338af7e..7e164da 100644
> > > --- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> > > +++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> > > @@ -54,6 +54,7 @@
> > >   dma0 = 
> > >   dma1 = 
> > >   sdhc = 
> > > + spi0 = 
> > >   };
> > >
> > >
> > > diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> > > b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> > > index 1948f73..b6e1724 100644
> > > --- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> > > +++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> > > @@ -54,6 +54,7 @@
> > >   dma0 = 
> > >   dma1 = 
> > >   sdhc = 
> > > + spi0 = 
> > >   };
> > >
> > >
> > > diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > > b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > > index 603910a..6fbd651 100644
> > > --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > > +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > > @@ -439,7 +439,7 @@
> > >   };
> > >
> > >  /include/ "qoriq-espi-0.dtsi"
> > > - spi@11 {
> > > + spi0: