* Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Ludovic BARRE @ 2017-04-10 9:08 UTC (permalink / raw)
To: Marek Vasut, Cyrille Pitchen
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5ec38e39-661d-8a83-4168-b9f3d986bcd1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/07/2017 01:55 AM, Marek Vasut wrote:
> On 03/31/2017 07:02 PM, Ludovic Barre wrote:
>> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>>
>> The quadspi is a specialized communication interface targeting single,
>> dual or quad SPI Flash memories.
>>
>> It can operate in any of the following modes:
>> -indirect mode: all the operations are performed using the quadspi
>> registers
>> -read memory-mapped mode: the external Flash memory is mapped to the
>> microcontroller address space and is seen by the system as if it was
>> an internal memory
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>> ---
>> drivers/mtd/spi-nor/Kconfig | 7 +
>> drivers/mtd/spi-nor/Makefile | 1 +
>> drivers/mtd/spi-nor/stm32-quadspi.c | 690 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 698 insertions(+)
>> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>>
> [...]
>
>> +struct stm32_qspi_flash {
>> + struct spi_nor nor;
>> + u32 cs;
>> + u32 fsize;
>> + u32 presc;
>> + struct stm32_qspi *qspi;
>> +};
> [...]
>
>> +struct stm32_qspi_cmd {
>> + struct {
>> + u8 addr_width;
>> + u8 dummy;
>> + u8 data;
>> + } conf;
> Is there any benefit in having this structure here or could you just
> make the struct stm32_qspi_cmd flat ?
no benefit, it was just to regroup, so I can do a flat structure
>
>> + u8 opcode;
>> + u32 framemode;
>> + u32 qspimode;
>> + u32 addr;
>> + size_t len;
>> + void *buf;
>> +};
> [...]
>
>> +static ssize_t stm32_qspi_read(struct spi_nor *nor, loff_t from, size_t len,
>> + u_char *buf)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> + struct stm32_qspi_cmd cmd;
>> + int err;
>> +
>> + dev_dbg(qspi->dev, "read(%#.2x): buf:%p from:%#.8x len:%#x\n",
>> + nor->read_opcode, buf, (u32)from, len);
>> +
>> + memset(&cmd, 0, sizeof(cmd));
>> + cmd.opcode = nor->read_opcode;
>> + cmd.conf.addr_width = nor->addr_width;
>> + cmd.addr = (u32)from;
> loff_t (from) can be 64bit ... how do we handle this ?
I'm surprise by the question,
the SPI NOR device uses 3 Bytes or 4 bytes address mode.
So, the stm32 qspi controller has a 32 bit register for NOR address.
On the other hand the framework and other drivers used this variable
(from) like
a 32 bits.
>
>> + cmd.conf.data = 1;
>> + cmd.conf.dummy = nor->read_dummy;
>> + cmd.len = len;
>> + cmd.buf = buf;
>> + cmd.qspimode = qspi->read_mode;
>> +
>> + stm32_qspi_set_framemode(nor, &cmd, true);
>> + err = stm32_qspi_send(flash, &cmd);
>> +
>> + return err ? err : len;
>> +}
> [...]
>
>> +static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
>> +{
>> + struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
>> + u32 cr, sr, fcr = 0;
>> +
>> + cr = readl_relaxed(qspi->io_base + QUADSPI_CR);
>> + sr = readl_relaxed(qspi->io_base + QUADSPI_SR);
>> +
>> + if ((cr & CR_TCIE) && (sr & SR_TCF)) {
>> + /* tx complete */
>> + fcr |= FCR_CTCF;
>> + complete(&qspi->cmd_completion);
>> + } else {
>> + dev_info(qspi->dev, "spurious interrupt\n");
> You probably want to ratelimit this one ...
yes it's better if there is an issue.
>
>> + }
>> +
>> + writel_relaxed(fcr, qspi->io_base + QUADSPI_FCR);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int stm32_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> +
>> + mutex_lock(&qspi->lock);
>> + return 0;
>> +}
>> +
>> +static void stm32_qspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> +
>> + mutex_unlock(&qspi->lock);
>> +}
>> +
>> +static int stm32_qspi_flash_setup(struct stm32_qspi *qspi,
>> + struct device_node *np)
>> +{
>> + u32 width, flash_read, presc, cs_num, max_rate = 0;
>> + struct stm32_qspi_flash *flash;
>> + struct mtd_info *mtd;
>> + int ret;
>> +
>> + of_property_read_u32(np, "reg", &cs_num);
>> + if (cs_num >= STM32_MAX_NORCHIP)
>> + return -EINVAL;
>> +
>> + of_property_read_u32(np, "spi-max-frequency", &max_rate);
>> + if (!max_rate)
>> + return -EINVAL;
>> +
>> + presc = DIV_ROUND_UP(qspi->clk_rate, max_rate) - 1;
>> +
>> + if (of_property_read_u32(np, "spi-rx-bus-width", &width))
>> + width = 1;
>> +
>> + if (width == 4)
>> + flash_read = SPI_NOR_QUAD;
>> + else if (width == 2)
>> + flash_read = SPI_NOR_DUAL;
>> + else if (width == 1)
>> + flash_read = SPI_NOR_NORMAL;
>> + else
>> + return -EINVAL;
>> +
>> + flash = &qspi->flash[cs_num];
>> + flash->qspi = qspi;
>> + flash->cs = cs_num;
>> + flash->presc = presc;
>> +
>> + flash->nor.dev = qspi->dev;
>> + spi_nor_set_flash_node(&flash->nor, np);
>> + flash->nor.priv = flash;
>> + mtd = &flash->nor.mtd;
>> + mtd->priv = &flash->nor;
>> +
>> + flash->nor.read = stm32_qspi_read;
>> + flash->nor.write = stm32_qspi_write;
>> + flash->nor.erase = stm32_qspi_erase;
>> + flash->nor.read_reg = stm32_qspi_read_reg;
>> + flash->nor.write_reg = stm32_qspi_write_reg;
>> + flash->nor.prepare = stm32_qspi_prep;
>> + flash->nor.unprepare = stm32_qspi_unprep;
>> +
>> + writel_relaxed(LPTR_DFT_TIMEOUT, qspi->io_base + QUADSPI_LPTR);
>> +
>> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN | CR_SSHIFT
>> + | CR_EN, qspi->io_base + QUADSPI_CR);
>> +
>> + /*
>> + * in stm32 qspi controller, QUADSPI_DCR register has a fsize field
>> + * which define the size of nor flash.
>> + * if fsize is NULL, the controller can't sent spi-nor command.
>> + * set a temporary value just to discover the nor flash with
>> + * "spi_nor_scan". After, the right value (mtd->size) can be set.
>> + */
> Is 25 the smallest value ? Use a macro for this ...
25 is an arbitrary choice, I will define a smallest value
>
>> + flash->fsize = 25;
>> +
>> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
>> + if (ret) {
>> + dev_err(qspi->dev, "device scan failed\n");
>> + return ret;
>> + }
>> +
>> + /* number of bytes in Flash memory = 2^[FSIZE+1] */
>> + flash->fsize = __fls(mtd->size) - 1;
>> +
>> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
>> +
>> + ret = mtd_device_register(mtd, NULL, 0);
>> + if (ret) {
>> + dev_err(qspi->dev, "mtd device parse failed\n");
>> + return ret;
>> + }
>> +
>> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
>> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num, width);
>> +
>> + return 0;
>> +}
> [...]
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Nicolas Ferre @ 2017-04-10 9:04 UTC (permalink / raw)
To: Ludovic Desroches,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Eugen.Hristev-UWL1GkI3JZL3oGB3hsPCZA, # 3 . 16+
In-Reply-To: <20170410082517.19628-2-ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Le 10/04/2017 à 10:25, Ludovic Desroches a écrit :
> Remove ADC channels that are not available by default on the sama5d3_xplained
> board (resistor not populated) in order to not create confusion.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16+
Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> index 7a0fa1a..5a53fcf 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -163,9 +163,9 @@
>
> adc0: adc@f8018000 {
> atmel,adc-vref = <3300>;
> + atmel,adc-channels-used = <0xfe>;
> pinctrl-0 = <
> &pinctrl_adc0_adtrg
> - &pinctrl_adc0_ad0
> &pinctrl_adc0_ad1
> &pinctrl_adc0_ad2
> &pinctrl_adc0_ad3
> @@ -173,8 +173,6 @@
> &pinctrl_adc0_ad5
> &pinctrl_adc0_ad6
> &pinctrl_adc0_ad7
> - &pinctrl_adc0_ad8
> - &pinctrl_adc0_ad9
> >;
> status = "okay";
> };
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Nicolas Ferre @ 2017-04-10 9:04 UTC (permalink / raw)
To: Ludovic Desroches, linux-arm-kernel, devicetree, linux-kernel
Cc: alexandre.belloni, Eugen.Hristev, # 3 . 16+
In-Reply-To: <20170410082517.19628-1-ludovic.desroches@microchip.com>
Le 10/04/2017 à 10:25, Ludovic Desroches a écrit :
> The voltage reference for the ADC is not 3V but 3.3V since it is connected to
> VDDANA.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> Cc: <stable@vger.kernel.org> # 3.16+
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> index c51fc65..7a0fa1a 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -162,6 +162,7 @@
> };
>
> adc0: adc@f8018000 {
> + atmel,adc-vref = <3300>;
> pinctrl-0 = <
> &pinctrl_adc0_adtrg
> &pinctrl_adc0_ad0
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series
From: Hans Verkuil @ 2017-04-10 8:55 UTC (permalink / raw)
To: Hugues Fruchet, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Mauro Carvalho Chehab
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, Benjamin Gaignard,
Yannick Fertre
In-Reply-To: <1491320678-17246-1-git-send-email-hugues.fruchet-qxv4g6HH51o@public.gmane.org>
On 04/04/2017 05:44 PM, Hugues Fruchet wrote:
> This patchset introduces a basic support for Digital Camera Memory Interface
> (DCMI) of STMicroelectronics STM32 SoC series.
>
> This first basic support implements RGB565 & YUV frame grabbing.
> Cropping and JPEG support will be added later on.
>
> This has been tested on STM324x9I-EVAL evaluation board embedding
> an OV2640 camera sensor.
>
> This driver depends on:
> - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers http://www.spinics.net/lists/linux-media/msg113480.html
>
> ===========
> = history =
> ===========
> version 3:
> - stm32-dcmi: Add "Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>"
> - dt-bindings: Fix remarks from Rob Herring:
> http://www.mail-archive.com/linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg110956.html
>
> version 2:
> - Fix a Kbuild warning in probe:
> http://www.mail-archive.com/linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg110678.html
> - Fix a warning in dcmi_queue_setup()
> - dt-bindings: warn on sensor signals level inversion in board example
> - Typos fixing
>
> version 1:
> - Initial submission
>
> ===================
> = v4l2-compliance =
> ===================
> Below is the v4l2-compliance report for this current version of the DCMI camera interface.
> v4l2-compliance has been built from v4l-utils-1.12.3.
Please test with 'v4l2-compliance -s -f' as well and mail me the output of
that test.
Once you have the Acks for the DT/bindings patches just let me know and I'll
make a pull request.
Regards,
Hans
>
> v4l2-compliance SHA : f5f45e17ee98a0ebad7836ade2b34ceec909d751
>
> Driver Info:
> Driver name : stm32-dcmi
> Card type : STM32 Digital Camera Memory Int
> Bus info : platform:dcmi
> Driver version: 4.11.0
> Capabilities : 0x85200001
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x05200001
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
>
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
>
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
>
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
>
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 3 Private Controls: 0
>
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK
>
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK
>
> Test input 0:
>
> Streaming ioctls:
> test read/write: OK
> test MMAP: OK
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
>
> Total: 46, Succeeded: 46, Failed: 0, Warnings: 0
>
> Hugues Fruchet (8):
> dt-bindings: Document STM32 DCMI bindings
> [media] stm32-dcmi: STM32 DCMI camera interface driver
> ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
> ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
> ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL
> board
> ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board
> ARM: configs: stm32: STMPE1600 GPIO expander
> ARM: configs: stm32: DCMI + OV2640 camera support
>
> .../devicetree/bindings/media/st,stm32-dcmi.txt | 46 +
> arch/arm/boot/dts/stm32429i-eval.dts | 56 +
> arch/arm/boot/dts/stm32f429.dtsi | 37 +
> arch/arm/configs/stm32_defconfig | 9 +
> drivers/media/platform/Kconfig | 12 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/stm32/Makefile | 1 +
> drivers/media/platform/stm32/stm32-dcmi.c | 1419 ++++++++++++++++++++
> 8 files changed, 1582 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
> create mode 100644 drivers/media/platform/stm32/Makefile
> create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-10 8:37 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAEHZuqM7YUxtN9F+5qqZ6HHBqLP0DuwotQv9ZyaN5UtrsN7j5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
>
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>> mode based on the type of cable connected to the port. The
>>>>> driver registers to extcon framework to get appropriate
>>>>> connect events for Host/Device cables connect/disconnect
>>>>> states based on VBUS and ID interrupts.
>>>>
>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>> Northstar2.
>>>>
>>>
>>> Will do.
>>>
>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>> notifications should be sent to the consumer driver and the consumer driver
>>>> should be responsible for invoking the phy ops.
>>>>
>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
>>>> The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>> set using extcon events might help.
>>
>
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
>
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.
Yes. We shouldn't add phy_ops just for the sake of it. I think this should be
made as a purely extcon driver (though there are a couple of bits that looks
like initializing PHY) and keep it in drivers/extcon.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 9/9] arm, arm64, drivers: add a prefix to drivers arch_topology interfaces
From: Catalin Marinas @ 2017-04-10 8:32 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.pieralisi-5wv7dgnIgG8,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
broonie-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dietmar.eggemann-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
sudeep.holla-5wv7dgnIgG8, linux-lFZ/pmaqli7XmaaqVzeoHQ,
morten.rasmussen-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327131825.32134-10-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 27, 2017 at 02:18:25PM +0100, Juri Lelli wrote:
> Now that some functions that deal with arch topology information live
> under drivers, there is a clash of naming that might create confusion.
>
> Tidy things up by creating a drivers namespace for interfaces used by
> arch code; achieve this by prepending a 'atd_' (arch topology driver)
> prefix to driver interfaces.
>
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 8 ++++----
> arch/arm64/kernel/topology.c | 4 ++--
> drivers/base/arch_topology.c | 20 ++++++++++----------
> include/linux/arch_topology.h | 8 ++++----
> 4 files changed, 20 insertions(+), 20 deletions(-)
Acked-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 8/9] arm,arm64,drivers: move externs in a new header file
From: Catalin Marinas @ 2017-04-10 8:31 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.pieralisi-5wv7dgnIgG8,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
broonie-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dietmar.eggemann-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
sudeep.holla-5wv7dgnIgG8, linux-lFZ/pmaqli7XmaaqVzeoHQ,
morten.rasmussen-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327131825.32134-9-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 27, 2017 at 02:18:24PM +0100, Juri Lelli wrote:
> Create a new header file (include/linux/arch_topology.h) and put there
> declarations of interfaces used by arm, arm64 and drivers code.
>
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 7 +------
> arch/arm64/kernel/topology.c | 4 +---
> drivers/base/arch_topology.c | 1 +
> include/linux/arch_topology.h | 17 +++++++++++++++++
> 4 files changed, 20 insertions(+), 9 deletions(-)
> create mode 100644 include/linux/arch_topology.h
Acked-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 7/9] arm,arm64,drivers: reduce scope of cap_parsing_failed
From: Catalin Marinas @ 2017-04-10 8:31 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, mark.rutland, devicetree, lorenzo.pieralisi,
vincent.guittot, linux-pm, peterz, broonie, will.deacon, gregkh,
dietmar.eggemann, robh+dt, sudeep.holla, linux, morten.rasmussen,
linux-arm-kernel
In-Reply-To: <20170327131825.32134-8-juri.lelli@arm.com>
On Mon, Mar 27, 2017 at 02:18:23PM +0100, Juri Lelli wrote:
> Reduce the scope of cap_parsing_failed (making it static in
> drivers/base/arch_topology.c) by slightly changing {arm,arm64} DT
> parsing code.
>
> For arm checking for !cap_parsing_failed before calling normalize_
> cpu_capacity() is superfluous, as returning an error from parse_
> cpu_capacity() (above) means cap_from _dt is set to false.
>
> For arm64 we can simply check if raw_capacity points to something,
> which is not if capacity parsing has failed.
>
> Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
> arch/arm/kernel/topology.c | 3 +--
> arch/arm64/kernel/topology.c | 5 +----
> drivers/base/arch_topology.c | 4 ++--
> 3 files changed, 4 insertions(+), 8 deletions(-)
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-10 8:30 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <a78f6948-0900-56f9-dc0c-5b161c470847-l0cyMroinI0@public.gmane.org>
Hi
On Mon, Apr 10, 2017 at 1:57 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
> Hi,
>
> On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
>> Hi,
>>
>> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>> Hi,
>>>
>>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>> Hi Ravi,
>>>>>
>>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>>> driver registers to extcon framework to get appropriate
>>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>>> states based on VBUS and ID interrupts.
>>>>>>>
>>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>>> Northstar2.
>>>>>>>
>>>>>>
>>>>>> Will do.
>>>>>>
>>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>>> should be responsible for invoking the phy ops.
>>>>>>>
>>>>>>
>>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>>> controller), EHCI and OHCI host controller drivers.
>>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>>
>>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>>> That's the design in Broadcom Northstar2
>>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>>> determined based on the type of the cable (device cable
>>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>>
>>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>>
>>>>>> Could you please elaborate on the concern, so that we can think of
>>>>>> mitigating those issues in this driver?
>>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>>> you okay with moving the extcon handling code
>>>>>> out of phy ops ?
>>>>>
>>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>>
>>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>>> set using extcon events might help.
>>>>>
>>>>
>>>> Say, we have a USB pendrive which is connected to the DRD port through
>>>> a host cable.
>>>> Now the PHY will be initialized to be in host mode.
>>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>>> some linux PC,
>>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>>
>>>> On unplug event, it is set neither to Host nor Device mode (basically
>>>> shutdown). Next time which ever cable is connected, the PHY is
>>>> initialized to the respective
>>>> mode.
>>>>
>>>> Please let me know if it's fine to do these initializations outside
>>>> phy ops, because those will
>>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>>> dealt in the phy driver through
>>>> extcon.
>>>
>>> How does the consumer get to know whether they have to operate in host mode or
>>> device mode?
>>>
>> In NS2, we have host controllers and device controller (not OTG/other
>> that can switch
>> between host and device mode). It's only phy that can be in host/device mode.
>> Since both Host Controllers and Device Controller are connected to the same PHY,
>> it is based on the extcon logic (the type of cable connected) that PHY
>> will be in one
>> of the modes host/device and the respective controller will operate.
>
> So at a point of time either the host controller or the device controller will
> be active? and the PHY decides which of them should be active? Is that right?
>
Yes
Thanks,
Ravi
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-10 8:27 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAEHZuqMJU=ZLL2xsbtpHLC6SU4uzNBpZmPPADs-g7=OXJyCbBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
> Hi,
>
> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>> Hi,
>>
>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>> Hi Ravi,
>>>>
>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>> Hi Kishon,
>>>>>
>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>> driver registers to extcon framework to get appropriate
>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>> states based on VBUS and ID interrupts.
>>>>>>
>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>> Northstar2.
>>>>>>
>>>>>
>>>>> Will do.
>>>>>
>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>> should be responsible for invoking the phy ops.
>>>>>>
>>>>>
>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>> controller), EHCI and OHCI host controller drivers.
>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>
>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>> That's the design in Broadcom Northstar2
>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>> determined based on the type of the cable (device cable
>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>
>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>
>>>>> Could you please elaborate on the concern, so that we can think of
>>>>> mitigating those issues in this driver?
>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>> you okay with moving the extcon handling code
>>>>> out of phy ops ?
>>>>
>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>
>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>> set using extcon events might help.
>>>>
>>>
>>> Say, we have a USB pendrive which is connected to the DRD port through
>>> a host cable.
>>> Now the PHY will be initialized to be in host mode.
>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>> some linux PC,
>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>
>>> On unplug event, it is set neither to Host nor Device mode (basically
>>> shutdown). Next time which ever cable is connected, the PHY is
>>> initialized to the respective
>>> mode.
>>>
>>> Please let me know if it's fine to do these initializations outside
>>> phy ops, because those will
>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>> dealt in the phy driver through
>>> extcon.
>>
>> How does the consumer get to know whether they have to operate in host mode or
>> device mode?
>>
> In NS2, we have host controllers and device controller (not OTG/other
> that can switch
> between host and device mode). It's only phy that can be in host/device mode.
> Since both Host Controllers and Device Controller are connected to the same PHY,
> it is based on the extcon logic (the type of cable connected) that PHY
> will be in one
> of the modes host/device and the respective controller will operate.
So at a point of time either the host controller or the device controller will
be active? and the PHY decides which of them should be active? Is that right?
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Ludovic Desroches @ 2017-04-10 8:25 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-kernel
Cc: nicolas.ferre, alexandre.belloni, Eugen.Hristev,
Ludovic Desroches, # 3 . 16+
In-Reply-To: <20170410082517.19628-1-ludovic.desroches@microchip.com>
Remove ADC channels that are not available by default on the sama5d3_xplained
board (resistor not populated) in order to not create confusion.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: <stable@vger.kernel.org> # 3.16+
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 7a0fa1a..5a53fcf 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -163,9 +163,9 @@
adc0: adc@f8018000 {
atmel,adc-vref = <3300>;
+ atmel,adc-channels-used = <0xfe>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
- &pinctrl_adc0_ad0
&pinctrl_adc0_ad1
&pinctrl_adc0_ad2
&pinctrl_adc0_ad3
@@ -173,8 +173,6 @@
&pinctrl_adc0_ad5
&pinctrl_adc0_ad6
&pinctrl_adc0_ad7
- &pinctrl_adc0_ad8
- &pinctrl_adc0_ad9
>;
status = "okay";
};
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Ludovic Desroches @ 2017-04-10 8:25 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Eugen.Hristev-UWL1GkI3JZL3oGB3hsPCZA, Ludovic Desroches,
# 3 . 16+
The voltage reference for the ADC is not 3V but 3.3V since it is connected to
VDDANA.
Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16+
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index c51fc65..7a0fa1a 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -162,6 +162,7 @@
};
adc0: adc@f8018000 {
+ atmel,adc-vref = <3300>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
&pinctrl_adc0_ad0
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 6/9] ARM: dts: add support for I2SE Duckbill 2 boards
From: Shawn Guo @ 2017-04-10 8:24 UTC (permalink / raw)
To: Michael Heimpold
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, stefan.wahren-eS4NqCHxEME,
fabio.estevam-3arQi8VN3Tc, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
Michael Heimpold
In-Reply-To: <1486626169-20022-7-git-send-email-michael.heimpold-eS4NqCHxEME@public.gmane.org>
On Thu, Feb 09, 2017 at 08:42:46AM +0100, Michael Heimpold wrote:
> From: Michael Heimpold <mhei-Z/Lg1yOAjpkb1SvskN2V4Q@public.gmane.org>
>
> This machine is an USB pen drive sized development board,
> based on NXP's i.MX28 CPU. In contrast to the previous
> model "Duckbill", the "Duckbill 2" series has internal
> eMMC storage.
>
> Signed-off-by: Michael Heimpold <mhei-Z/Lg1yOAjpkb1SvskN2V4Q@public.gmane.org>
> Cc: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx28-duckbill-2.dts | 183 +++++++++++++++++++++++++++++++++
> arch/arm/mach-mxs/mach-mxs.c | 3 +-
I'm preparing pull request for 4.12 merge window, and found this.
C file change shouldn't be mixed in DTS patch, so I dropped it. Please
submit C code change in a separate patch.
Shawn
> 3 files changed, 186 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx28-duckbill-2.dts
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
From: Y.B. Lu @ 2017-04-10 8:20 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Adrian Hunter, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon
Cc: Xiaobo Xie
In-Reply-To: <1490600982-5410-1-git-send-email-yangbo.lu@nxp.com>
Hi Andrian and Uffe,
Do you have any comments on MMC patches?
Could you help to merge the mmc patches if there is no changes requested?
Regarding to the dts patches, I have some more platforms to support.
So I'd like to drop them currently, and send them all to arm mailing list for reviewing.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Y.B. Lu
> Sent: Thursday, April 06, 2017 4:02 PM
> To: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Adrian
> Hunter; Rob Herring; Mark Rutland; Catalin Marinas; Will Deacon
> Cc: Xiaobo Xie
> Subject: RE: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
>
> Hi all,
>
> Any comments? Thanks.
>
>
> Best regards,
> Yangbo Lu
>
> > -----Original Message-----
> > From: Yangbo Lu [mailto:yangbo.lu-3arQi8VN3Tc@public.gmane.org]
> > Sent: Monday, March 27, 2017 3:50 PM
> > To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Adrian Hunter; Rob
> > Herring; Mark Rutland; Catalin Marinas; Will Deacon
> > Cc: Xiaobo Xie; Y.B. Lu
> > Subject: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
> >
> > It's complicated to support SD UHS-I and eMMC HS200 for eSDHC because
> > there're many differences between eSDHC and SD/eMMC spec. Several
> > differences as below must be considered:
> > 1. Peripheral clock must be used instead of platform clock.
> > - eSDHC could select peripheral clock or platform clock as its
> clock
> > source. According to RM, UHS-I/HS200 must use peripheral clock
> > since
> > it supports higher frequency than platform clock.
> > - Patch 1 and patch 6 is to support this.
> > 2. Signal voltage switching requires a control circuit out of eSDHC.
> > - eSDHC supports signal voltage switch from 3.3v to 1.8v by
> > eSDHC_PROCTL[VOLT_SEL] bit. This bit changes the value of output
> > signal SDHC_VS, and there must be a control circuit out of eSDHC
> > to change the signal voltage according to SDHC_VS output signal.
> > - Patch 2 is to support this.
> > 3. eSDHC uses tuning block for tuning procedure.
> > - Tuning clock control register must be configured before tuning.
> > - Patch 3 is to support this.
> > 4. Delay is needed between tuning cycles for HS200 tuning.
> > - Once a patch removed mdelay between tuning cycles.
> > But eSDHC needs it.
> > - Patch 4 and patch 5 is to support this.
> > 5. UHS-I/HS200 modes could be enabled in dts node.
> > - Patch 7 is to support this.
> >
> > Please review and merge these patches on mmc git tree if no changes
> > are required.
> >
> > Adrian Hunter (1):
> > mmc: sdhci: Control the delay between tuning commands
> >
> > Yangbo Lu (6):
> > mmc: sdhci-of-esdhc: add peripheral clock support
> > mmc: sdhci-of-esdhc: add support for signal voltage switch
> > mmc: sdhci-of-esdhc: add tuning support
> > mmc: sdhci-of-esdhc: add delay between tuning cycles
> > arm64: dts: ls1046a: add clocks property and compatible for eSDHC
> node
> > arm64: dts: ls1046ardb: add MMC HS200/UHS-1 modes support
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++
> > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +-
> > drivers/mmc/host/sdhci-esdhc.h | 7 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 165
> > +++++++++++++++++++++-
> > drivers/mmc/host/sdhci.c | 11 +-
> > drivers/mmc/host/sdhci.h | 2 +
> > 6 files changed, 190 insertions(+), 6 deletions(-)
> >
> > --
> > 2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 5/9] arm, arm64: factorize common cpu capacity default code
From: Catalin Marinas @ 2017-04-10 8:18 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, mark.rutland, devicetree, lorenzo.pieralisi,
vincent.guittot, linux-pm, peterz, broonie, will.deacon, gregkh,
dietmar.eggemann, Russell King, robh+dt, sudeep.holla, linux,
morten.rasmussen, linux-arm-kernel
In-Reply-To: <20170327131825.32134-6-juri.lelli@arm.com>
On Mon, Mar 27, 2017 at 02:18:21PM +0100, Juri Lelli wrote:
> arm and arm64 share lot of code relative to parsing CPU capacity
> information from DT, using that information for appropriate scaling and
> exposing a sysfs interface for chaging such values at runtime.
>
> Factorize such code in a common place (driver/base/arch_topology.c) in
> preparation for further additions.
>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
>
> Changes from v2:
> - make capacity_scale and raw_capacity static
> - added SPDX header
> - improved indent
> - misc. whitespaces/newlines fixes
>
> Changes from v1:
> - keep the original GPLv2 header
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/kernel/topology.c | 213 ++-----------------------------------
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/topology.c | 219 +--------------------------------------
> drivers/base/Kconfig | 8 ++
> drivers/base/Makefile | 1 +
> drivers/base/arch_topology.c | 242 +++++++++++++++++++++++++++++++++++++++++++
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH net-next v2] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-10 7:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, David S. Miller, Joao Pinto,
Alexandre TORGUE, Giuseppe CAVALLARO, Thierry Reding,
Eric Engestrom
Cc: Niklas Cassel, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.
Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..84e4cbfd3b0f 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -8,8 +8,8 @@ Required properties:
that services interrupts for this device
- interrupts: Should contain the STMMAC interrupts
- interrupt-names: Should contain the interrupt names "macirq"
- "eth_wake_irq" if this interrupt is supported in the "interrupts"
- property
+ "eth_wake_irq" if this interrupt is supported in the "interrupts" property
+ "eth_lpi" if this interrupt is supported in the "interrupts" property
- phy-mode: See ethernet.txt file in the same directory.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +152,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe0800000 0x8000>;
interrupt-parent = <&vic1>;
- interrupts = <24 23>;
- interrupt-names = "macirq", "eth_wake_irq";
+ interrupts = <24 23 22>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = [000000000000]; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-10 7:43 UTC (permalink / raw)
To: Sergei Shtylyov, Rob Herring, Mark Rutland, David S. Miller,
Joao Pinto, Alexandre TORGUE, Giuseppe CAVALLARO, Thierry Reding,
Eric Engestrom
Cc: netdev, devicetree, linux-kernel
In-Reply-To: <c1e78674-64d1-0e51-3ca4-48d8500a3528@cogentembedded.com>
On 04/07/2017 06:48 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 04/07/2017 05:30 PM, Niklas Cassel wrote:
>
>> From: Niklas Cassel <niklas.cassel@axis.com>
>>
>> The hardware has a LPI interrupt.
>> There is already code in the stmmac driver to parse and handle the
>> interrupt. However, this information was missing from the DT binding.
>>
>> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
>> ---
>> Documentation/devicetree/bindings/net/stmmac.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
>> index f652b0c384ce..8977abc266ac 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -8,8 +8,8 @@ Required properties:
>> that services interrupts for this device
>> - interrupts: Should contain the STMMAC interrupts
>> - interrupt-names: Should contain the interrupt names "macirq"
>> - "eth_wake_irq" if this interrupt is supported in the "interrupts"
>> - property
>> + "eth_wake_irq" if this interrupt is supported in the "interrupts property
>
> Missed closing quote?
Thanks for pointing it out.
Will send a v2.
>
>> + "eth_lpi" if this interrupt is supported in the "interrupts" property
>> - phy-mode: See ethernet.txt file in the same directory.
>> - snps,reset-gpio gpio number for phy reset.
>> - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-10 7:27 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree, linux-kernel,
BCM Kernel Feedback, linux-arm-kernel
In-Reply-To: <9fbef986-721c-05aa-28a1-4c49016fe2ca@ti.com>
Hi,
On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi Ravi,
>>>
>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>> mode based on the type of cable connected to the port. The
>>>>>> driver registers to extcon framework to get appropriate
>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>> states based on VBUS and ID interrupts.
>>>>>
>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>> Northstar2.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>> should be responsible for invoking the phy ops.
>>>>>
>>>>
>>>> The consumer drivers here would be a UDC driver (USB device
>>>> controller), EHCI and OHCI host controller drivers.
>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>
>>>> This phy connects to 2 host controllers, and one device controller.
>>>> That's the design in Broadcom Northstar2
>>>> platform. The values of the VBUS and ID pins of this port are
>>>> determined based on the type of the cable (device cable
>>>> or host cable). And. phy has to be configured accordingly.
>>>>
>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>
>>>> Could you please elaborate on the concern, so that we can think of
>>>> mitigating those issues in this driver?
>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>> you okay with moving the extcon handling code
>>>> out of phy ops ?
>>>
>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>
>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>> set using extcon events might help.
>>>
>>
>> Say, we have a USB pendrive which is connected to the DRD port through
>> a host cable.
>> Now the PHY will be initialized to be in host mode.
>> When the pendrive is unplugged, and we now connect the NS2 device to
>> some linux PC,
>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>
>> On unplug event, it is set neither to Host nor Device mode (basically
>> shutdown). Next time which ever cable is connected, the PHY is
>> initialized to the respective
>> mode.
>>
>> Please let me know if it's fine to do these initializations outside
>> phy ops, because those will
>> be irrelevant for phy consumers (the controllers) as it's anyways
>> dealt in the phy driver through
>> extcon.
>
> How does the consumer get to know whether they have to operate in host mode or
> device mode?
>
In NS2, we have host controllers and device controller (not OTG/other
that can switch
between host and device mode). It's only phy that can be in host/device mode.
Since both Host Controllers and Device Controller are connected to the same PHY,
it is based on the extcon logic (the type of cable connected) that PHY
will be in one
of the modes host/device and the respective controller will operate.
> Thanks
> Kishon
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support
From: Alexandre Torgue @ 2017-04-10 7:23 UTC (permalink / raw)
To: Vikas Manocha, patrice.chotard-qxv4g6HH51o
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list, Mark Rutland, Maxime Coquelin,
Rob Herring, Russell King
In-Reply-To: <1491613929-11485-1-git-send-email-vikas.manocha-qxv4g6HH51o@public.gmane.org>
Hi
On 04/08/2017 03:12 AM, Vikas Manocha wrote:
> Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major
> spces of the two boards:
>
> stm32f769I discovery board:
> - Cortex-M7 core @216MHz
> - 2MB mcu internal flash
> - 512KB internal sram
> - 16MB sdram memory
> - 64MB qspi flash memory
> - 4 inch wvga LCD-TFT Display
>
> stm32f746 discovery board:
> - Cortex-M7 core @216MHz
> - 1MB mcu internal flash
> - 320KB internal sram
> - 8MB sdram memory
> - 16MB qspi flash memory
> - 4.3 inch 480x272 LCD-TFT display
>
> Signed-off-by: Vikas Manocha <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/stm32f746-disco.dts | 101 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f746.dtsi | 2 +-
> arch/arm/boot/dts/stm32f769-disco.dts | 101 ++++++++++++++++++++++++++++++++++
> 4 files changed, 205 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/stm32f746-disco.dts
> create mode 100644 arch/arm/boot/dts/stm32f769-disco.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0118084..a119f74 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -763,6 +763,8 @@ dtb-$(CONFIG_ARCH_STI) += \
> dtb-$(CONFIG_ARCH_STM32)+= \
> stm32f429-disco.dtb \
> stm32f469-disco.dtb \
> + stm32f746-disco.dtb \
> + stm32f769-disco.dtb \
> stm32429i-eval.dtb \
> stm32746g-eval.dtb
> dtb-$(CONFIG_MACH_SUN4I) += \
> diff --git a/arch/arm/boot/dts/stm32f746-disco.dts b/arch/arm/boot/dts/stm32f746-disco.dts
> new file mode 100644
> index 0000000..c0e313f
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f746-disco.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> + *
> + * 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 "stm32f746.dtsi"
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "STMicroelectronics STM32F746-DISCO board";
> + compatible = "st,stm32f746-disco", "st,stm32f746";
> +
> + chosen {
> + bootargs = "root=/dev/ram";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0xC0000000 0x800000>;
> + };
> +
> + aliases {
> + serial0 = &usart1;
> + };
> +
> +};
> +
> +&clk_hse {
> + clock-frequency = <25000000>;
> +};
> +
> +&pinctrl {
Pin muxing is not defined in board file. Please move it into SOC dtsi file.
> + usart1_pins: usart1@0 {
> + pins1 {
> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + pins2 {
> + pinmux = <STM32F746_PB7_FUNC_USART1_RX>;
> + bias-disable;
> + };
> + };
> +
> + qspi_pins: qspi@0 {
> + pins {
> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> + <STM32F746_PD11_FUNC_QUADSPI_BK1_IO0>,
> + <STM32F746_PD12_FUNC_QUADSPI_BK1_IO1>,
> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> + slew-rate = <2>;
> + };
> + };
> +};
> +
> +&usart1 {
> + pinctrl-0 = <&usart1_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
> index f321ffe..826700f 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -178,7 +178,7 @@
> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> };
>
> - pin-controller {
> + pinctrl: pin-controller {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "st,stm32f746-pinctrl";
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
> new file mode 100644
> index 0000000..5f8558e
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> + *
> + * 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 "stm32f746.dtsi"
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "STMicroelectronics STM32F769-DISCO board";
> + compatible = "st,stm32f769-disco", "st,stm32f7";
> +
> + chosen {
> + bootargs = "root=/dev/ram";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0xC0000000 0x1000000>;
> + };
> +
> + aliases {
> + serial0 = &usart1;
> + };
> +
> +};
> +
> +&clk_hse {
> + clock-frequency = <25000000>;
> +};
> +
> +&pinctrl {
same.
> + usart1_pins: usart1@0 {
> + pins1 {
> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + pins2 {
> + pinmux = <STM32F746_PA10_FUNC_USART1_RX>;
> + bias-disable;
> + };
> + };
> +
> + qspi_pins: qspi@0 {
> + pins {
> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> + <STM32F746_PC9_FUNC_QUADSPI_BK1_IO0>,
> + <STM32F746_PC10_FUNC_QUADSPI_BK1_IO1>,
> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> + slew-rate = <2>;
> + };
> + };
> +};
> +
> +&usart1 {
> + pinctrl-0 = <&usart1_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: allwinner: h5: add support for Orange Pi Prime board
From: Maxime Ripard @ 2017-04-10 7:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170407165630.7632-1-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
On Sat, Apr 08, 2017 at 12:56:30AM +0800, Icenowy Zheng wrote:
> Orange Pi Prime is a new Allwinner H5-based SBC by Xunlong.
>
> It's like a Orange Pi Plus 2E with H3 replaced with H5, eMMC replaced
> with onboard SPI NOR Flash and wireless card changed to Realtek
> RTL8723BS (with Bluetooth functionality).
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 202 +++++++++++++++++++++
> 2 files changed, 203 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 244e8b7565f9..92a84eea6b96 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,6 +1,7 @@
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
> new file mode 100644
> index 000000000000..2ebfe6c359ed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
You're sure?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 6:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <CAJKOXPe_+Y+9ZLE7Jymqc5nULzo+qM4cCMFg2-cV_YnpCFkRCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10-04-17, 08:45, Krzysztof Kozlowski wrote:
> Yes, keeping both make most sense, I think.
>
> Anyway, I found now the original report thread of Masahiro and I see
> Mark's response about using '-'. In that case I am fine with this. I
> would prefer to take only the exynos part (separated to ARMv7 and
> ARMv8) through my tree but I already sent a pull request so I am fine
> with this going directly to arm-soc.
This may end up going via the PM tree.
> I think you need to update also:
> Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
Oops. I searched for opp@ and missed the complex ones. There are some
DT files as well for TI which I missed. Will send a V2 with all that
fixed.
> With that change:
> Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> (and implied acked-by)
Thanks.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Krzysztof Kozlowski @ 2017-04-10 6:45 UTC (permalink / raw)
To: Viresh Kumar
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel, linux-pm, Linux Kernel Mailing List
In-Reply-To: <20170410063239.GB24555@vireshk-i7>
On Mon, Apr 10, 2017 at 8:32 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-04-17, 15:30, Masahiro Yamada wrote:
>> 2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
>> > On 10-04-17, 10:46, Viresh Kumar wrote:
>> >> Compiling the DT file with W=1, DTC warns like follows:
>> >>
>> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
>> >> unit name, but no reg property
>> >>
>> >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>> >> "reg" property.
>> >>
>> >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > + Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > --
>> > viresh
>>
>>
>> Given that this had already been reported one year before,
>> the reported-by credit should be given to Krzysztof.
>>
>> Please drop my Reported-by.
>
> I don't think we need to drop any of you. We can very well keep both
> :)
Yes, keeping both make most sense, I think.
Anyway, I found now the original report thread of Masahiro and I see
Mark's response about using '-'. In that case I am fine with this. I
would prefer to take only the exynos part (separated to ARMv7 and
ARMv8) through my tree but I already sent a pull request so I am fine
with this going directly to arm-soc.
I think you need to update also:
Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
With that change:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
(and implied acked-by)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Chanwoo Choi @ 2017-04-10 6:42 UTC (permalink / raw)
To: Viresh Kumar, Rafael Wysocki, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Mark Rutland, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Maxime Ripard, Chen-Yu Tsai, Masahiro Yamada
Cc: linaro-kernel, linux-pm, linux-kernel, Vincent Guittot,
linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <5ce1fbbc7cd37a6cfe54e93eeca311a7a52093ff.1491801395.git.viresh.kumar@linaro.org>
Hi,
On 2017년 04월 10일 14:16, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
> arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> arch/arm/boot/dts/pxa25x.dtsi | 8 +--
> arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
> arch/arm/boot/dts/sun8i-a33.dtsi | 8 +--
> arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
> arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
> 18 files changed, 280 insertions(+), 280 deletions(-)
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
[snip]
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 6:32 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Rafael Wysocki, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Mark Rutland, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Maxime Ripard, Chen-Yu Tsai, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <CAK7LNAR=+k6iuqUPUNLW=EHUuOw4fBr4SbEtP-jnSyrsiEydgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10-04-17, 15:30, Masahiro Yamada wrote:
> 2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> > On 10-04-17, 10:46, Viresh Kumar wrote:
> >> Compiling the DT file with W=1, DTC warns like follows:
> >>
> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> >> unit name, but no reg property
> >>
> >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> >> "reg" property.
> >>
> >> Reported-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> >> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> > + Reported-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > --
> > viresh
>
>
> Given that this had already been reported one year before,
> the reported-by credit should be given to Krzysztof.
>
> Please drop my Reported-by.
I don't think we need to drop any of you. We can very well keep both
:)
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Masahiro Yamada @ 2017-04-10 6:30 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Mark Rutland, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Maxime Ripard, Chen-Yu Tsai, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <20170410062258.GA24555@vireshk-i7>
2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On 10-04-17, 10:46, Viresh Kumar wrote:
>> Compiling the DT file with W=1, DTC warns like follows:
>>
>> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
>> unit name, but no reg property
>>
>> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>> "reg" property.
>>
>> Reported-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
>> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> + Reported-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> --
> viresh
Given that this had already been reported one year before,
the reported-by credit should be given to Krzysztof.
Please drop my Reported-by.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox