* Re: [RFC PATCH v12 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
From: Andy Shevchenko @ 2017-12-28 8:47 UTC (permalink / raw)
To: Rob Herring, JeffyChen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Bjorn Helgaas, linux-pm-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
Shawn Lin, Brian Norris, Rafael J. Wysocki, Doug Anderson,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Frank Rowand
In-Reply-To: <CAL_JsqJssPABjoRM-XAnuN_Xd2-sHoFifJNrRDdk_ruQ0DRw6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2017-12-27 at 09:30 -0600, Rob Herring wrote:
> On Tue, Dec 26, 2017 at 7:32 PM, JeffyChen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> wrote:
> this new file does something similar to the pci-acpi.c and pci-mid.c..
> pci-acpi.c has similar things to pci/of.c. The naming is just not
> consistent.
> > and i am agree the naming is not clear, maybe we can rename both of
> > those
> > files to something like pci-pm-***.c?
>
> At least pci-acpi.c is more than just PM functions, so that doesn't
> make sense. Given that all the ACPI related functions are in 1 file,
> we should do the same for DT.
> > but i have no idea about pci-mid.c or would it possible to have more
> > platform pm ops in the future...maybe we should add some dependency
> > in the
> > Kconfig?
You may consider pci-mid.c as pci-sfi.c to some extend.
So, in that sense it more looks like pci-of.c would be the name for DT
case.
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
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 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI
From: Cyrille Pitchen @ 2017-12-28 9:36 UTC (permalink / raw)
To: Trent Piepho, broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
radu.pirea-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
vigneshr-l0cyMroinI0@public.gmane.org,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
richard-/L3Ra7n9ekc@public.gmane.org,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1514405711.26695.67.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
Hi Trent,
Le 27/12/2017 à 21:15, Trent Piepho a écrit :
> On Wed, 2017-12-27 at 10:36 +0000, Mark Brown wrote:
>> On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
>>
>>> Or, since this only fixes instances of DMA-unsafe buffers used in
>>> access to SPI NOR flash chips, and since there are other SPI master
>>> interface users, those chip specific fixes in some/all spi master
>>> drivers are still needed to fix transfers not originated via spi-nor?
>>
>> SPI client drivers are *supposed* to use DMA safe memory already. How
>> often that happens in cases where it matters is a separate question, we
>> definitely have users with smaller transfers that don't do the right
>> thing but they're normally done using PIO anyway.
>
> I wonder what the end goal is here?
>
> A random collection of spi master drivers will accept DMA-unsafe
> buffers in some way. In some cases a framework like spi-nor provides
> the fixup to spi-nor master drivers (none so far) and in other cases
> (atmel-quadspi), the spi-nor master driver has its own fixes.
>
At the spi-nor side, atmel-quadspi is also an example showing how the
bounce buffer feature should be used by other spi-flash drivers.
Actually, the m25p80 driver taken aside, no spi-flash driver is currently
able to perform DMA safe transfers.
Some patches were proposed but all rejected because they were doing wrong
things: calling dma_map_single() even if the buffer is not guaranteed to be
contiguous in physical memory or not being aware of the data cache aliasing
issue on some architectures.
So this series offers a common helper solution for all drivers in spi-nor.
I don't want each spi-flash driver to implement its own custom solution.
> Generic spi masters like spi-atmel, spi-ti-qspi, and spi-davinci will
> have their fixes for certain cases.
>
If UBIFS was the only reason for those drivers to implement their own fixes
then those fixes would no longer be needed with this series. However if
other spi-clients also provide the SPI sub-system with DMA-unsafe buffers
then maybe those fixes are still needed. I think Mark knows better than
anyone else about the SPI sub-system.
Besides, another reason to allocate the bounce buffer from spi-nor is that
we can choose a suited size as a trade-off between performance and memory
footprint.
> Perhaps spi flash drivers like m25p80 will have fixes too?
>
patch 1 of the series enables the bounce buffer for both read and write
operations in the m25p80 driver, in order to be compliant with buffer
constraints expressed in the kernel-doc of 'struct spi_transfer'.
> Some spi clients, like spidev, will have internal bounce buffers,
> rather than userspace addresses or commands in stack variables, so that
> they follow the rules about DMA safe buffers.
>
> What exactly is caught as DMA unsafe and what is not will of course
> vary greatly from driver to driver. Some drivers will catch highmem
> memory while other drivers will only detect vmalloc memory. Some will
> only catch an unsafe buffer if a specific SoC known to the driver to
> have an aliasing cache is enabled. Some will check buffers that arrive
> via the spi_flash_read interface but not via generic spi transfers,
> while others will check all spi transfer buffers.
>
That's why I've asked for pieces of advice on how to implement a relevant
[spi_nor_]is_dma_safe() function and Vignesh has provided good suggestion!
> Obviously, I don't think this path will lead to a desirable end. Maybe
Here you seem to only take the m25p80 and SPI sub-system cases into
account. However, at the spi-nor side, we currently have to other solution
to let spi-nor flash drivers implement DMA transfers safely.
Best regards,
Cyrille
> the basic assumption, that clients should provide DMA safe buffers,
> should be revisited. Experience has shown that it's too much to ask
> for and spi clients will never get it right. It would be better to try
> to fix this at some common point between the clients and masters so it
> can be done once and for all.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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/3] mtd: spi-nor: add optional DMA-safe bounce buffer for data transfer
From: Cyrille Pitchen @ 2017-12-28 10:39 UTC (permalink / raw)
To: Trent Piepho,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
vigneshr-l0cyMroinI0@public.gmane.org,
richard-/L3Ra7n9ekc@public.gmane.org,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
radu.pirea-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1514317385.26695.39.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
Hi Trent,
Le 26/12/2017 à 20:43, Trent Piepho a écrit :
> On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote:
>>
>> Then the patch adds two hardware capabilities for SPI flash controllers,
>> SNOR_HWCAPS_WR_BOUNCE and SNOR_HWCAPS_RD_BOUNCE.
>
> Are there any drivers for which a bounce buffer is NOT needed when the
> tx/rx buffer is not in DMA safe memory? Maybe it would make more sense
> to invert the sense of these flags, so that they indicate the driver
> does not need DMA safe buffers, if that is the uncommon/non-existent
> case, so that fewer drivers need to be modified to to be fixed?
>
It doesn't sound safe for a first step. I don't know if some of the
spi-flash controllers are embedded inside systems with small memory and
don't care about DMA transfers. Maybe they don't plan to use anything else
but PIO transfers. Then why taking the risk to exhaust the memory on systems
that would not use the bounce buffer anyway?
Later, if we see that most spi-flash drivers actually need this bounce
buffer, I agree with you: we could invert the logic of the flags but
currently I guess this is too soon and to be safe I would have to add the
negative flags to all other spi-flash drivers. I would like a smooth and
safe transition to avoid unexpected and unwanted side effects.
About the memory loss when forcing the SNOR_HWCAPS_*_BOUNCE in m25p80.c, I
justify it because the m25p80 has to be compliant with the SPI sub-system
requirements but currently is not. However I've taken care not to allocate
the bounce buffer as long as we use only DMA-safe buffers.
Here at the MTD side, the main (only ?) source of DMA-unsafe buffers is
the UBIFS (JFFS2 too ?) layer. Then I've assumed that systems using such a
file-system should already have enough system memory.
However I wanted to take all other use cases into account.
>> +static bool spi_nor_is_dma_safe(const void *buf)
>> +{
>> + if (is_vmalloc_addr(buf))
>> + return false;
>> +
>> +#ifdef CONFIG_HIGHMEM
>> + if ((unsigned long)buf >= PKMAP_BASE &&
>> + (unsigned long)buf < (PKMAP_BASE + (LAST_PKMAP * PAGE_SIZE)))
>> + return false;
>> +#endif
>
> It looks like:
>
> (unsigned long)addr >= PKMAP_ADDR(0) &&
> (unsigned long)addr < PKMAP_ADDR(LAST_PKMAP)
>
> is the expression used in the highmem code. But really, isn't this
> begging for is_highmem_addr() in include/linux/mm.h that can always
> return false when highmem is not enabled?
>
Vignesh has suggested to call virt_addr_valid() instead.
I think Boris has also told me about this function.
So it might be the right solution. What do you think about their proposal?
> In order to be safe, this must be called when nor->lock is held, right?
Indeed, in all cases (spi_nor_read(), sst_write() and spi_nor_write()),
spi_nor_get_bounce_buffer() is always called with nor->lock held, precisely
to avoid races and allocating the bounce buffer twice by mistake.
> Otherwise it could race against two callers allocating the buffer at
> the same time. That should probably be noted in the kerneldoc comments
> for this function, which should also be written.
>
I can add kernel-doc.
>> +static int spi_nor_get_bounce_buffer(struct spi_nor *nor,
>> + u_char **buffer,
>> + size_t *buffer_size)
>> +{
>
>> +
>> + *buffer = nor->bounce_buffer;
>> + *buffer_size = size;
>
> So the buffer is returned via the parameter, and also via a field
> inside nor. Seems redundant. Consider address could be returned via
> the function return value coupled with PTR_ERR() for the error cases.
> Or not return address at all since it's available via nor-
>> bounce_buffer.
>
Why not. It would require more lines though. I guess it's purely a matter of taste.
u_char *buffer = buf;
if (use_bounce) {
buffer = spi_nor_get_bounce_buffer(nor, &buffer_size);
if (IS_ERR(buffer)) {
err = PTR_ERR(buffer);
goto read_err;
}
}
>> {
>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>> + bool use_bounce = (nor->flags & SNOR_F_USE_RD_BOUNCE) &&
>> + !spi_nor_is_dma_safe(buf);
>> + u_char *buffer = buf;
>> + size_t buffer_size = 0;
>> int ret;
>>
>> dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
>> @@ -1268,13 +1324,23 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
>> if (ret)
>> return ret;
>>
>> + if (use_bounce) {
>> + ret = spi_nor_get_bounce_buffer(nor, &buffer, &buffer_size);
>> + if (ret < 0)
>> + goto read_err;
>> + }
>
> This pattern, check if bounce is enabled, check if address is dma-
> unsafe, get bounce buffer, seems to be very common. Could it be
> refactored into one helper?
>
> u_char *buffer = spi_nor_check_bounce(nor, buf, len, &buffer_size);
The conditions that define the value of 'use_bounce' also depend on the type
of operation, read or write, hence on the two different flags
SNOR_F_USE_RD_BOUNCE and SNOR_F_USE_WR_BOUNCE.
Besides, 'use_bounce' is also tested later in spi_nor_read(), sst_write()
and sst_write().
So I don't really see how the spi_nor_check_bounce() function you propose
could be that different from spi_nor_get_bounce_buffer().
> if (IS_ERR(buffer))
> return PTR_ERR(buffer);
> // buffer = nor->bounce_buffer or buf, whichever is correct
> // buffer_size = len or bounce buffer size, whichever is correct
>
> Could spi_nor_read_sfdp_dma_unsafe() also use this buffer?
>
I didn't use the bounce buffer in spi_nor_read_sfdp_dma_unsafe() on
purpose: the bounce buffer, when needed, is allocated once for all to limit
performance loss. However, to avoid increasing the memory footprint, if not
absolutely needed the bounce buffer is not allocated at all.
For a SFDP compliant memory, spi_nor_parse_sfdp() is always called during
spi_nor_scan() even if later, only DMA-safe buffers are provided. In such a
case, allocating the bounce buffer would have been a waste of memory.
Best regards,
Cyrille
--
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 v4 0/4] eeprom: at24: device tree support fixes
From: Bartosz Golaszewski @ 2017-12-28 10:49 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
The first three patches fix certain issues with the DT binding
document.
The last two extend the device tree support in the driver with more
at24 EEPROM variants.
v1 -> v2:
- remove any implementation details from patch 1/5
v2 -> v3:
- reword patch 1/5: allow any "<manufacturer>,<vendor>" pair as long
as a supported fallback is used
v3 -> v4:
- another shot at correct wording of the compatible property description
- squashed patches 1/5 and 2/5
Bartosz Golaszewski (4):
dt-bindings: at24: consistently document the compatible property
dt-bindings: at24: fix formatting and style
dt-bindings: at24: extend the list of supported chips
eeprom: at24: extend the list of chips supported in DT
Documentation/devicetree/bindings/eeprom/at24.txt | 91 ++++++++++++++---------
drivers/misc/eeprom/at24.c | 9 +++
2 files changed, 66 insertions(+), 34 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: at24: consistently document the compatible property
From: Bartosz Golaszewski @ 2017-12-28 10:49 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171228104913.29873-1-brgl@bgdev.pl>
Current description of the compatible property for at24 is quite vague.
State explicitly that any "<manufacturer>,<model>" pair is accepted as
long as a correct fallback is used for non-atmel chips.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 58 ++++++++++++++---------
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index cbc80e194ac6..0c8e1341908f 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -2,28 +2,42 @@ EEPROMs (I2C)
Required properties:
- - compatible : should be "<manufacturer>,<type>", like these:
-
- "atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
- "atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
- "atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"
-
- "catalyst,24c32"
-
- "microchip,24c128"
-
- "ramtron,24c64"
-
- "renesas,r1ex24002"
-
- The following manufacturers values have been deprecated:
- "at", "at24"
-
- If there is no specific driver for <manufacturer>, a generic
- device with <type> and manufacturer "atmel" should be used.
- Possible types are:
- "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
- "24c128", "24c256", "24c512", "24c1024", "spd"
+ - compatible: Must be a "<manufacturer>,<model>" pair. The following <model>
+ values are supported (assuming "atmel" as manufacturer):
+
+ "atmel,24c00",
+ "atmel,24c01",
+ "atmel,24c02",
+ "atmel,spd",
+ "atmel,24c04",
+ "atmel,24c08",
+ "atmel,24c16",
+ "atmel,24c32",
+ "atmel,24c64",
+ "atmel,24c128",
+ "atmel,24c256",
+ "atmel,24c512",
+ "atmel,24c1024",
+
+ If <manufacturer> is not "atmel", then a fallback must be used
+ with the same <type> and "atmel" as manufacturer.
+
+ Example:
+ compatible = "microchip,24c128", "atmel,24c128";
+
+ Supported manufacturers are:
+
+ "catalyst",
+ "microchip",
+ "ramtron",
+ "renesas",
+ "nxp",
+ "st",
+
+ Some vendors use different model names for chips which are just
+ variants of the above. Known such exceptions are listed below:
+
+ "renesas,r1ex24002" - the fallback is "atmel,24c02"
- reg : the I2C address of the EEPROM
--
2.15.1
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: at24: fix formatting and style
From: Bartosz Golaszewski @ 2017-12-28 10:49 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171228104913.29873-1-brgl@bgdev.pl>
Make formatting and style consistent for the entire document.
This patch doesn't change the content of the binding.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index 0c8e1341908f..5e0dfd25b1e3 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -39,23 +39,23 @@ Required properties:
"renesas,r1ex24002" - the fallback is "atmel,24c02"
- - reg : the I2C address of the EEPROM
+ - reg: The I2C address of the EEPROM.
Optional properties:
- - pagesize : the length of the pagesize for writing. Please consult the
- manual of your device, that value varies a lot. A wrong value
- may result in data loss! If not specified, a safety value of
- '1' is used which will be very slow.
+ - pagesize: The length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
- - read-only: this parameterless property disables writes to the eeprom
+ - read-only: This parameterless property disables writes to the eeprom.
- - size: total eeprom size in bytes
+ - size: Total eeprom size in bytes.
- - no-read-rollover:
- This parameterless property indicates that the multi-address
- eeprom does not automatically roll over reads to the next
- slave address. Please consult the manual of your device.
+ - no-read-rollover: This parameterless property indicates that the
+ multi-address eeprom does not automatically roll over
+ reads to the next slave address. Please consult the
+ manual of your device.
- wp-gpios: GPIO to which the write-protect pin of the chip is connected.
--
2.15.1
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: at24: extend the list of supported chips
From: Bartosz Golaszewski @ 2017-12-28 10:49 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bartosz Golaszewski
In-Reply-To: <20171228104913.29873-1-brgl-ARrdPY/1zhM@public.gmane.org>
Add other variants of at24 EEPROMs we support in the driver to the
list of allowed compatible fallbacks.
Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
Reviewed-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index 5e0dfd25b1e3..6fc05e24fa7f 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -7,13 +7,22 @@ Required properties:
"atmel,24c00",
"atmel,24c01",
+ "atmel,24cs01",
"atmel,24c02",
+ "atmel,24cs02",
+ "atmel,24mac402",
+ "atmel,24mac602",
"atmel,spd",
"atmel,24c04",
+ "atmel,24cs04",
"atmel,24c08",
+ "atmel,24cs08",
"atmel,24c16",
+ "atmel,24cs16",
"atmel,24c32",
+ "atmel,24cs32",
"atmel,24c64",
+ "atmel,24cs64",
"atmel,24c128",
"atmel,24c256",
"atmel,24c512",
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 4/4] eeprom: at24: extend the list of chips supported in DT
From: Bartosz Golaszewski @ 2017-12-28 10:49 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171228104913.29873-1-brgl@bgdev.pl>
Add all supported at24 variants to the of_match table.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/misc/eeprom/at24.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index e79833d62284..01f9c4921c50 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -209,13 +209,22 @@ MODULE_DEVICE_TABLE(i2c, at24_ids);
static const struct of_device_id at24_of_match[] = {
{ .compatible = "atmel,24c00", .data = &at24_data_24c00 },
{ .compatible = "atmel,24c01", .data = &at24_data_24c01 },
+ { .compatible = "atmel,24cs01", .data = &at24_data_24cs01 },
{ .compatible = "atmel,24c02", .data = &at24_data_24c02 },
+ { .compatible = "atmel,24cs02", .data = &at24_data_24cs02 },
+ { .compatible = "atmel,24mac402", .data = &at24_data_24mac402 },
+ { .compatible = "atmel,24mac602", .data = &at24_data_24mac602 },
{ .compatible = "atmel,spd", .data = &at24_data_spd },
{ .compatible = "atmel,24c04", .data = &at24_data_24c04 },
+ { .compatible = "atmel,24cs04", .data = &at24_data_24cs04 },
{ .compatible = "atmel,24c08", .data = &at24_data_24c08 },
+ { .compatible = "atmel,24cs08", .data = &at24_data_24cs08 },
{ .compatible = "atmel,24c16", .data = &at24_data_24c16 },
+ { .compatible = "atmel,24cs16", .data = &at24_data_24cs16 },
{ .compatible = "atmel,24c32", .data = &at24_data_24c32 },
+ { .compatible = "atmel,24cs32", .data = &at24_data_24cs32 },
{ .compatible = "atmel,24c64", .data = &at24_data_24c64 },
+ { .compatible = "atmel,24cs64", .data = &at24_data_24cs64 },
{ .compatible = "atmel,24c128", .data = &at24_data_24c128 },
{ .compatible = "atmel,24c256", .data = &at24_data_24c256 },
{ .compatible = "atmel,24c512", .data = &at24_data_24c512 },
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v4 1/4] dt-bindings: at24: consistently document the compatible property
From: Andy Shevchenko @ 2017-12-28 11:57 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Javier Martinez Canillas,
David Lechner, Divagar Mohandass, Peter Rosin, linux-i2c,
devicetree, Linux Kernel Mailing List
In-Reply-To: <20171228104913.29873-2-brgl@bgdev.pl>
On Thu, Dec 28, 2017 at 12:49 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> Current description of the compatible property for at24 is quite vague.
>
> State explicitly that any "<manufacturer>,<model>" pair is accepted as
> long as a correct fallback is used for non-atmel chips.
> - "atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
> - "atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
> - "atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"
> + "atmel,24c00",
> + "atmel,24c01",
> + "atmel,24c02",
> + "atmel,spd",
> + "atmel,24c04",
Just to whom it may concern, I still don't like the ordering.
By name is better to read and catch up the (un)supported chips.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
From: Rafael J. Wysocki @ 2017-12-28 12:18 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rafael J. Wysocki, Rafael J. Wysocki, JeffyChen,
Linux Kernel Mailing List, Bjorn Helgaas, Linux PM, Shawn Lin,
Brian Norris, Doug Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux PCI,
Rob Herring, Frank Rowand
In-Reply-To: <20171228042205.GG3875-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Thu, Dec 28, 2017 at 5:22 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [171228 00:51]:
>> On Wed, Dec 27, 2017 at 4:08 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>> > * Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> [171227 01:00]:
>> >> On Tuesday, December 26, 2017 2:06:47 AM CET JeffyChen wrote:
>> >> > Hi Rafael,
>> >> >
>> >> > Thanks for your reply :)
>> >> >
>> >> > On 12/26/2017 08:11 AM, Rafael J. Wysocki wrote:
>> >> > >> >+
>> >> > >> >+ dn = pci_device_to_OF_node(ppdev);
>> >> > >> >+ if (!dn)
>> >> > >> >+ return 0;
>> >> > >> >+
>> >> > >> >+ irq = of_irq_get_byname(dn, "wakeup");
>> >> > > Why is this a property of the bridge and not of the device itself?
>> >> >
>> >> > That is suggested by Brian, because in that way, the wakeup pin would
>> >> > not "tied to what exact device is installed (or no device, if it's a slot)."
>> >>
>> >> But I don't think it works when there are two devices using different WAKE#
>> >> interrupt lines under the same bridge. Or how does it work then?
>> >
>> > It won't work currently for multiple devices but adding more than
>> > one wakeriq per device is doable. And I think we will have other
>> > cases where multiple wakeirqs are connected to a single device, so
>> > that issue should be sorted out sooner or later.
>> >
>> > And if requesting wakeirq for the PCI WAKE# lines at the PCI
>> > controller does the job, then maybe that's all we need to start with.
>>
>> These are expected to be out-of-band, so not having anything to do
>> with the Root Complex.
>>
>> In-band PME Messages go through the PCIe hierarchy, but that is a
>> standard mechanism and it is supported already.
>>
>> WAKE# are platform-specific, pretty much by definition and I guess
>> that on most ARM boards they are just going to be some kind of GPIO
>> pins.
>
> OK. So probably supporting the following two configurations
> should be enough then:
>
> 1. One or more WAKE# lines configured as a wakeirq for the PCI
> controller
>
> When the wakeirq calls pm_wakeup_event() for the PCI controller
> device driver, the PCI controller wakes up and can deal with
> it's child devices
But this shouldn't be necessary at all. Or if it is, I wonder why
that's the case.
I'm assuming that we're talking about PCI Express here, which has two
wakeup mechanisms defined, one of which is based on using PME Messages
(Beacon) and the second one is WAKE#:
"The WAKE# mechanism uses sideband signaling to implement wakeup
functionality. WAKE# is
an “open drain” signal asserted by components requesting wakeup and
observed by the associated
power controller."
(from PCIe Base Spec 3.0). [And there's a diagram showing the routing
of WAKE# in two cases in Figure 5-4: Conceptual Diagrams Showing Two
Example Cases of WAKE# Routing.]
Note that WAKE# is defined to be "observed by the associated power
controller", so I'm not sure what the PCI controller's role in the
handing of it is at all.
> 2. Optionally a WAKE# line from a PCI device configured as wakeirq
> for the PCI device driver
>
> In this case calling the PM runtime resume in the child
> PCI device will also wake up the parent PCI controller,
> and then the PCI controller can deal with it's children
>
> Seems like this series is pretty close to 1 above except
> we need to have a list of wakeirqs per device instead of
> just one. And option 2 should already work as long as the
> PCI device driver parses and configures the wakeirq.
Well, this is confusing, because as I said above, option 1 doesn't
look relevant even.
>> > Then in addition to that, we could do the following to allow
>> > PCI devices to request the wakeirq from the PCI controller:
>> >
>> > 1. PCI controller or framework implements a chained irq for
>> > the WAKE# lines assuming it can mask/unmask the WAKE# lines
>> >
>> > 2. PCI devices then can just request the wakeirq from the PCI
>> > controller
>> >
>> > And that's about it. Optionally we could leave out the dependency
>> > to having PCI devices implement PM runtime and just resume the
>> > parent (PCI controller) if PCI devices has not implemented
>> > PM runtime.
>>
>> So if my understanding is correct, DT should give you the WAKE# IRQ
>> for the given endpoint PCI device and you only are expected to request
>> it. The rest should just follow from the other pieces of information
>> in the DT.
>
> Yeah and it seems that we should allow configuring both cases
> 1 and 2 above.
>
>> With the quite obvious caveat that the same IRQ may be used as WAKE#
>> for multiple endpoint devices (which BTW need not be under the same
>> bridge even).
>
> And with the shared interrupts we can't do the masking/unmasking
> automatically..
Or we need to use reference counting (so actually the wakeup IRQs are
not dedicated).
>> >> > >> >+ if (irq == -EPROBE_DEFER)
>> >> > > Braces here, please.
>> >> > ok, will fix in the next version.
>> >> >
>> >> > >
>> >> > >> >+ return irq;
>> >> > >> >+ /* Ignore other errors, since a missing wakeup is non-fatal. */
>> >> > >> >+ else if (irq < 0) {
>> >> > >> >+ dev_info(&pdev->dev, "cannot get wakeup interrupt: %d\n", irq);
>> >> > >> >+ return 0;
>> >> > >> >+ }
>> >> > >> >+
>> >> > >> >+ device_init_wakeup(&pdev->dev, true);
>> >> > > Why do you call this before dev_pm_set_dedicated_wake_irq()?
>> >> >
>> >> > hmmm, i thought so too, but it turns out the dedicated wake irq
>> >> > framework requires device_init_wakeup(dev, true) before attach the wake irq:
>> >> >
>> >> > int device_wakeup_attach_irq(struct device *dev,
>> >> > struct wake_irq *wakeirq)
>> >> > {
>> >> > struct wakeup_source *ws;
>> >> >
>> >> > ws = dev->power.wakeup;
>> >> > if (!ws) {
>> >> > dev_err(dev, "forgot to call device_init_wakeup?\n");
>> >> > return -EINVAL;
>> >> >
>> >>
>> >> Well, that's a framework issue, fair enough.
>> >>
>> >> That said, what if user space removes the wakeup source from under you
>> >> concurrently via sysfs? Tony?
>> >
>> > Hmm sounds racy, need to take a look.
>>
>> Not only racy, as I don't see anything to prevent user space from
>> making the dev->power.wakeup wakeup source go away via sysfs at any
>> time *after* the IRQ has been requested.
>
> Currently nothing happens with wakeirqs if there's no struct
> wakeup_source. On device_wakeup_enable() we call device_wakeup_attach()
> that just copies dev->power.wakeirq to ws->wakeirq. And when struct
> wake_source is freed the device should be active and wakeirq
> disabled. Or are you seeing other issues here?
I'm suspicious about one thing, but I need to look deeper into the code. :-)
>> Pretty much right after dev_pm_set_dedicated_wake_irq() has returned,
>> device_wakeup_disable() may be called on the device via wakeup_store()
>> and it doesn't even check if the device has a wakeup irq.
>>
>> > I think the only reason
>> > to have the wakeirq pointer there was to save memory. It might
>> > make sense to remove the wakeirq dependency here.
>>
>> Well, that looks necessary to be honest.
>
> Seems like we're OK there except for the race. But I still wonder
> if could just get rid of wakeirq in struct wakeup_source. Maybe
> all we need is to see if dev->power.wakeup is allocated for the
> wakeirqs.
I guess "no", but let me get back to you when I have looked at things
in more detail.
Thanks,
Rafael
--
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/4] ASoC: mediatek: fix error handling in mt2701_afe_pcm_dev_probe()
From: Ryder Lee @ 2017-12-28 12:27 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Garlic Tseng
In-Reply-To: <18b7f0ec484300af795b1873efab96e51393459c.1514190169.git.ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Sorry, please ignore this series. I will send new ones later.
On Mon, 2017-12-25 at 16:28 +0800, Ryder Lee wrote:
> Fix unbalanced error handling path which will get incorrect counts
> if probe failed. The .remove() should be adjusted accordingly.
>
> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> index 8fda182..b3f6f73 100644
> --- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> +++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> @@ -1591,8 +1591,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, afe);
> pm_runtime_enable(&pdev->dev);
> - if (!pm_runtime_enabled(&pdev->dev))
> - goto err_pm_disable;
> + if (!pm_runtime_enabled(&pdev->dev)) {
> + ret = mt2701_afe_runtime_resume(&pdev->dev);
> + if (ret)
> + goto err_pm_disable;
> + }
> +
> pm_runtime_get_sync(&pdev->dev);
>
> ret = snd_soc_register_platform(&pdev->dev, &mtk_afe_pcm_platform);
> @@ -1610,16 +1614,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
> goto err_dai_component;
> }
>
> - mt2701_afe_runtime_resume(&pdev->dev);
> -
> return 0;
>
> err_dai_component:
> - snd_soc_unregister_component(&pdev->dev);
> -
> -err_platform:
> snd_soc_unregister_platform(&pdev->dev);
> -
> +err_platform:
> + pm_runtime_put_sync(&pdev->dev);
> err_pm_disable:
> pm_runtime_disable(&pdev->dev);
>
> @@ -1628,17 +1628,14 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
>
> static int mt2701_afe_pcm_dev_remove(struct platform_device *pdev)
> {
> - struct mtk_base_afe *afe = platform_get_drvdata(pdev);
> -
> + pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> if (!pm_runtime_status_suspended(&pdev->dev))
> mt2701_afe_runtime_suspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
>
> snd_soc_unregister_component(&pdev->dev);
> snd_soc_unregister_platform(&pdev->dev);
> - /* disable afe clock */
> - mt2701_afe_disable_clock(afe);
> +
> 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] ARM: dts: sun8i: add support for Orange Pi R1
From: Hauke Mehrtens @ 2017-12-28 12:42 UTC (permalink / raw)
To: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171112124129.15844-1-icenowy-h8G6r0blFSE@public.gmane.org>
Hi,
I tried this device tree file with my Orange Pi R1 and then the Ethernet
chip connected to the USB controller is not working. When I set PAD 20
to high the device is found on the USB bus.
On 11/12/2017 01:41 PM, Icenowy Zheng wrote:
> Orange Pi R1 is a board design based on Orange Pi Zero, with XR819 Wi-Fi
> chip replaced by RTL8189ETV Wi-Fi module and the USB Type-A jack
> replaced by an onboard USB RTL8152B USB-Ethernet adapter.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 73 +++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..3c139c63098f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -949,6 +949,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a83t-bananapi-m3.dtb \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-a83t-tbs-a711.dtb \
> + sun8i-h2-plus-orangepi-r1.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> sun8i-h3-beelink-x2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> new file mode 100644
> index 000000000000..32a6d312422e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy-ymACFijhrKM@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.
> + */
> +
> +/* Orange Pi R1 is based on Orange Pi Zero design */
> +#include "sun8i-h2-plus-orangepi-zero.dts"
> +
> +/ {
> + model = "Xunlong Orange Pi R1";
> + compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
> +
> + /delete-node/ reg_vcc_wifi;
I remove this line.
> +
> + aliases {
> + ethernet1 = &rtl8189etv;
> + };
> +};
> +
I add this:
®_vcc_wifi {
regulator-always-on;
};
This regulator should be connected to the USB device, but this is not in
device tree because it should be automatically probed.
> +&ohci1 {
> + /*
> + * RTL8152B USB-Ethernet adapter is connected to USB1,
> + * and it's a USB 2.0 device. So the OHCI1 controller
> + * can be left disabled.
> + */
> + status = "disabled";
> +};
> +
> +&mmc1 {
> + vmmc-supply = <®_vcc3v3>;
> + vqmmc-supply = <®_vcc3v3>;
> +
> + rtl8189etv: sdio_wifi@1 {
> + reg = <1>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Fix power for USB Ethernet controller
From: Hauke Mehrtens @ 2017-12-28 12:52 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM
Cc: icenowy-h8G6r0blFSE, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Hauke Mehrtens
The RTL8152B USB controller needs a 3.3 volt power supply which is
controlled by PAD20. Without this patch Linux will not see that there is
a device connected to the USB bus and the 2. USB port will not work.
I do not of a better solution to add a regulator to a USB device.
Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
index 32a6d312422e..1d5db0e0bd12 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -47,13 +47,15 @@
model = "Xunlong Orange Pi R1";
compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
- /delete-node/ reg_vcc_wifi;
-
aliases {
ethernet1 = &rtl8189etv;
};
};
+®_vcc_wifi {
+ regulator-always-on;
+};
+
&ohci1 {
/*
* RTL8152B USB-Ethernet adapter is connected to USB1,
--
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] dt: psci: Update DT bindings to support hierarchical PSCI states
From: Ulf Hansson @ 2017-12-28 13:00 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Sudeep Holla, Lorenzo Pieralisi,
Brendan Jackman, Lina Iyer, Kevin Hilman,
Linux Kernel Mailing List, linux-arm-kernel
In-Reply-To: <20171226221311.4vx7f3kmcvt5t6gt@rob-hp-laptop>
On 26 December 2017 at 23:13, Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 22, 2017 at 03:32:07PM +0100, Ulf Hansson wrote:
>> From: Lina Iyer <lina.iyer@linaro.org>
>>
>> Update DT bindings to represent hierarchical CPU and CPU domain idle states
>> for PSCI. Also update the PSCI examples to clearly show how flattened and
>> hierarchical idle states can be represented in DT.
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>>
>> For your information, I have picked up the work from Lina Iyer around the so
>> called CPU cluster idling series [1,2] and I working on new versions. However,
>> I decided to post the updates to the PSCI DT bindings first, as they will be
>> needed to be agreed upon before further changes can be done to the PSCI firmware
>> driver.
>>
>> Note, these bindings have been discussed over and over again, at LKML, but
>> especially also at various Linux conferences, like LPC and Linaro Connect. We
>> finally came to a conclusion and the changes we agreed upon, should be reflected
>> in this update.
>>
>> Of course, it's a while ago since the latest discussions, but hopefully people
>> don't have too hard time to remember.
>
> Vaguely...
>
>>
>> Kind regards
>> Uffe
>>
>> [1]
>> https://www.spinics.net/lists/arm-kernel/msg566200.html
>>
>> [2]
>> https://lwn.net/Articles/716300/
>>
>> ---
>> Documentation/devicetree/bindings/arm/psci.txt | 152 +++++++++++++++++++++++++
>> 1 file changed, 152 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>> index a2c4f1d..5a8f11b 100644
>> --- a/Documentation/devicetree/bindings/arm/psci.txt
>> +++ b/Documentation/devicetree/bindings/arm/psci.txt
>> @@ -105,7 +105,159 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>> ...
>> };
>>
>> +PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPUs and CPU
>> +clusters from the firmware. For such topologies the PSCI firmware driver acts
>> +as pseudo-controller, which may be specified in the psci DT node. The
>> +definitions of the CPU and the CPU cluster topology, must conform to the domain
>> +idle state specification [3]. The domain idle states themselves, must be
>> +compatible with the defined 'domain-idle-state' binding [1], and also need to
>> +specify the arm,psci-suspend-param property for each idle state.
>> +
>> +DT allows representing CPU and CPU cluster idle states in two different ways -
>> +
>> +The flattened model as given in Example 1, lists CPU's idle states followed by
>> +the domain idle state that the CPUs may choose. This is the general practice
>> +followed in PSCI firmwares that support Platform Coordinated mode. Note that
>> +the idle states are all compatible with "arm,idle-state".
>> +
>> +Example 2 represents the hierarchical model of CPU and domain idle states.
>> +CPUs define their domain provider in their DT node. The domain controls the
>> +power to the CPU and possibly other h/w blocks that would be powered off when
>> +the CPU is powered off. The CPU's idle states may therefore be considered as
>> +the domain's idle states and have the compatible "arm,idle-state". Such domains
>> +may be embedded within another domain that represents common h/w blocks between
>> +these CPUs viz. the cluster. The idle states of the cluster would be
>> +represented as the domain's idle states. In order to use OS-Initiated mode of
>> +PSCI in the firmware, the hierarchical representation must be used.
>> +
>> +Example 1: Flattened representation of CPU and domain idle states
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + reg = <0x0>;
>> + enable-method = "psci";
>> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
>> + <&CLUSTER_PWR_DWN>;
>> + };
>> +
>> + CPU1: cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x100>;
>> + enable-method = "psci";
>> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
>> + <&CLUSTER_PWR_DWN>;
>> + };
>> +
>> + idle-states {
>> + CPU_PWRDN: cpu_power_down{
>
> Use '-' rather than '_'. dtc has more warnings since last time...
Yes, I found this on a couple of more places and fixed them all.
>
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x000001>;
>> + entry-latency-us = <10>;
>> + exit-latency-us = <10>;
>> + min-residency-us = <100>;
>> + };
>> +
>> + CLUSTER_RET: domain_ret {
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x1000010>;
>> + entry-latency-us = <500>;
>> + exit-latency-us = <500>;
>> + min-residency-us = <2000>;
>> + };
>> +
>> + CLUSTER_PWR_DWN: domain_off {
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x1000030>;
>> + entry-latency-us = <2000>;
>> + exit-latency-us = <2000>;
>> + min-residency-us = <6000>;
>> + };
>> + };
>> +
>> + psci {
>> + compatible = "arm,psci-0.2";
>> + method = "smc";
>> + };
>> +
>> +Example 2: Hierarchical representation of CPU and domain idle states
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + reg = <0x0>;
>> + enable-method = "psci";
>> + power-domains = <&CPU_PD0>;
>> + };
>> +
>> + CPU1: cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x100>;
>> + enable-method = "psci";
>> + power-domains = <&CPU_PD1>;
>> + };
>> +
>> + idle-states {
>> + CPU_PWRDN: cpu_power_down{
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x000001>;
>> + entry-latency-us = <10>;
>> + exit-latency-us = <10>;
>> + min-residency-us = <100>;
>> + };
>> +
>> + CLUSTER_RET: domain_ret {
>> + compatible = "domain-idle-state";
>> + arm,psci-suspend-param = <0x1000010>;
>> + entry-latency-us = <500>;
>> + exit-latency-us = <500>;
>> + min-residency-us = <2000>;
>> + };
>> +
>> + CLUSTER_PWR_DWN: domain_off {
>> + compatible = "domain-idle-state";
>> + arm,psci-suspend-param = <0x1000030>;
>> + entry-latency-us = <2000>;
>> + exit-latency-us = <2000>;
>> + min-residency-us = <6000>;
>> + };
>> + };
>> + };
>> +
>> + psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> +
>> + CPU_PD0: cpu-pd@0 {
>
> A unit address without reg property is now a warning.
There is currently no need for reg property, so let me replace this with:
CPU_PD0: cpu-pd0
>
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CPU_PWRDN>;
>> + power-domains = <&CLUSTER_PD>;
>> + };
>> +
>> + CPU_PD1: cpu-pd@1 {
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CPU_PWRDN>;
>> + power-domains = <&CLUSTER_PD>;
>
> Could this node be a child of CLUSTER_PD rather than having a phandle?
> Doesn't matter so much here, but when you have 3 levels?
This follows existing bindings for power-domains as per
Documentation/devicetree/bindings/power/power_domain.txt. I guess it's
better to stick to that!?
>
>> + };
>
> These 2 nodes are identical, so why do you need both?
Each node represents a power domain, which contains devices (in this
case CPUs) that are specific to each power domain.
In other words, we are trying to describe the HW using a hierarchical layout.
>
>> +
>> + CLUSTER_PD: cluster-pd@0 {
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>> + };
>> + };
>> +
>> [1] Kernel documentation - ARM idle states bindings
>> Documentation/devicetree/bindings/arm/idle-states.txt
>> [2] Power State Coordination Interface (PSCI) specification
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
>> +[3]. PM Domains description
>> + Documentation/devicetree/bindings/power/power_domain.txt
>> --
>> 2.7.4
>>
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 0/9] PCI: Add support to the Cadence PCIe controller
From: Kishon Vijay Abraham I @ 2017-12-28 13:00 UTC (permalink / raw)
To: Cyrille Pitchen, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
lorenzo.pieralisi-5wv7dgnIgG8, linux-pci-u79uwXL29TY76Z2rM5mHXA
Cc: adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1513620412.git.cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Cyrille,
On Monday 18 December 2017 11:46 PM, Cyrille Pitchen wrote:
> Hi all,
>
> this series of patches adds support to the Cadence PCIe controller.
> It was tested on a ARM64 platform emulated by a Palladium running the
> pci-next kernel.
>
> The host mode was tested with some PCIe devices connected to the Palladium
> through a speed-bridge. Some of those devices were a USB host controller
> and a SATA controller. The PCIe host controller was also tested with a
> second controller configured in endpoint mode and connected back to back
> to the first controller.
>
> The EndPoint Controller (EPC) driver of this series was tested with the
> pci-epf-test.c EndPoint Function (EPF) driver and the pcitest userspace
> program.
Did you get to test multi function EP?
Thanks
Kishon
>
> For pci-next, I applied this series on top of Kishon's patch
> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>
> Best regards,
>
> Cyrille
>
> ChangeLog:
>
> v1 -> v2:
> - add new properties in the device-tree bindings: 'cdns,max-outbound-regions'
> and 'cdns,no-bar-match-nbits'.
> - add a new patch to regroup all makefile rules in drivers/pci/Makefile, hence
> cleaning drivers/Makefile up.
> - change the license text to use the recommanded format:
> // SPDX-License-Identifier: GPL-2.0
> - add a new patch updating the API of the EPC library to add support to
> multi-function devices.
> - add a 2 new patches to share more common code between host controller drivers
> - remove some useless tests
> - add more comments in both drivers.
> - fix DT bindings examples
> - remove useless init of the primary, secondary and sub-ordinate bus numbers in
> the PCI configuration space of the root port.
> - remove cdns_pcie_ep_stop() function and rework cdns_pcie_ep_start() function
>
> Cyrille Pitchen (8):
> PCI: Regroup all PCI related entries into drivers/pci/Makefile
> PCI: OF: Add generic function to parse and allocate PCI resources
> PCI: Add generic function to probe PCI host controllers
> PCI: Add vendor ID for Cadence
> PCI: cadence: Add host driver for Cadence PCIe controller
> PCI: endpoint: Add the function number as argument to EPC ops
> dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint
> controller
> PCI: cadence: Add EndPoint Controller driver for Cadence PCIe
> controller
>
> Scott Telford (1):
> dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe host
> controller
>
> .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt | 23 +
> .../bindings/pci/cdns,cdns-pcie-host.txt | 60 +++
> MAINTAINERS | 7 +
> drivers/Makefile | 5 +-
> drivers/pci/Kconfig | 2 +
> drivers/pci/Makefile | 12 +-
> drivers/pci/cadence/Kconfig | 33 ++
> drivers/pci/cadence/Makefile | 4 +
> drivers/pci/cadence/pcie-cadence-ep.c | 531 +++++++++++++++++++++
> drivers/pci/cadence/pcie-cadence-host.c | 330 +++++++++++++
> drivers/pci/cadence/pcie-cadence.c | 95 ++++
> drivers/pci/cadence/pcie-cadence.h | 310 ++++++++++++
> drivers/pci/dwc/pcie-designware-ep.c | 20 +-
> drivers/pci/endpoint/functions/pci-epf-test.c | 41 +-
> drivers/pci/endpoint/pci-epc-core.c | 62 ++-
> drivers/pci/host/Makefile | 2 +
> drivers/pci/host/pci-host-common.c | 87 +---
> drivers/pci/of.c | 51 ++
> drivers/pci/probe.c | 50 ++
> include/linux/pci-epc.h | 43 +-
> include/linux/pci.h | 12 +
> include/linux/pci_ids.h | 2 +
> 22 files changed, 1624 insertions(+), 158 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> create mode 100644 Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> create mode 100644 drivers/pci/cadence/Kconfig
> create mode 100644 drivers/pci/cadence/Makefile
> create mode 100644 drivers/pci/cadence/pcie-cadence-ep.c
> create mode 100644 drivers/pci/cadence/pcie-cadence-host.c
> create mode 100644 drivers/pci/cadence/pcie-cadence.c
> create mode 100644 drivers/pci/cadence/pcie-cadence.h
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: Fix power for USB Ethernet controller
From: Icenowy Zheng @ 2017-12-28 13:01 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171228125222.12942-1-hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
在 2017年12月28日星期四 CST 下午8:52:22，Hauke Mehrtens 写道：
> The RTL8152B USB controller needs a 3.3 volt power supply which is
> controlled by PAD20. Without this patch Linux will not see that there is
> a device connected to the USB bus and the 2. USB port will not work.
>
> I do not of a better solution to add a regulator to a USB device.
I have one.
Please check the patch I will send you soon.
>
> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts index
> 32a6d312422e..1d5db0e0bd12 100644
> --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> @@ -47,13 +47,15 @@
> model = "Xunlong Orange Pi R1";
> compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
>
> - /delete-node/ reg_vcc_wifi;
> -
> aliases {
> ethernet1 = &rtl8189etv;
> };
> };
>
> +®_vcc_wifi {
> + regulator-always-on;
> +};
> +
> &ohci1 {
> /*
> * RTL8152B USB-Ethernet adapter is connected to USB1,
--
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 0/3] Ingenic JZ4770 and earlycon support
From: Paul Cercueil @ 2017-12-28 13:07 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Rob Herring, linux-serial, devicetree, linux-kernel
Hi Greg, list,
I split this set of 3 patches from another patchset that was sent to the
MIPS mailing list (JZ4770 & GCW0 patchset) but never merged.
That's why patch 2/3 already has an ACK from Rob.
Cheers,
- Paul Cercueil
^ permalink raw reply
* [PATCH 1/3] serial: core: Make uart_parse_options take const char* argument
From: Paul Cercueil @ 2017-12-28 13:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Cercueil
In-Reply-To: <20171228130709.12457-1-paul-icTtO2rgO2OTuSrc4Mpeew@public.gmane.org>
The pointed string is never modified from within uart_parse_options, so
it should be marked as const in the function prototype.
Signed-off-by: Paul Cercueil <paul-icTtO2rgO2OTuSrc4Mpeew@public.gmane.org>
---
drivers/tty/serial/serial_core.c | 5 +++--
include/linux/serial_core.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
v1: Initial version
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 854995e1cae7..4e0c9209bfb7 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1955,9 +1955,10 @@ EXPORT_SYMBOL_GPL(uart_parse_earlycon);
* eg: 115200n8r
*/
void
-uart_parse_options(char *options, int *baud, int *parity, int *bits, int *flow)
+uart_parse_options(const char *options, int *baud, int *parity,
+ int *bits, int *flow)
{
- char *s = options;
+ const char *s = options;
*baud = simple_strtoul(s, NULL, 10);
while (*s >= '0' && *s <= '9')
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 37b044e78333..e23d9aa757fb 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -387,7 +387,7 @@ struct uart_port *uart_get_console(struct uart_port *ports, int nr,
struct console *c);
int uart_parse_earlycon(char *p, unsigned char *iotype, resource_size_t *addr,
char **options);
-void uart_parse_options(char *options, int *baud, int *parity, int *bits,
+void uart_parse_options(const char *options, int *baud, int *parity, int *bits,
int *flow);
int uart_set_options(struct uart_port *port, struct console *co, int baud,
int parity, int bits, int flow);
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] serial: 8250_ingenic: Add support for the JZ4770 SoC
From: Paul Cercueil @ 2017-12-28 13:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, linux-serial, devicetree, linux-kernel,
Paul Cercueil
In-Reply-To: <20171228130709.12457-1-paul@crapouillou.net>
The JZ4770 SoC's UART is no different from the other JZ SoCs, so this
commit simply adds the ingenic,jz4770-uart compatible string.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/serial/ingenic,uart.txt | 8 ++++++--
drivers/tty/serial/8250/8250_ingenic.c | 5 +++++
2 files changed, 11 insertions(+), 2 deletions(-)
v1: Initial version
diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.txt b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
index 02cb7fe59cb7..c3c6406d5cfe 100644
--- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt
+++ b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
@@ -1,8 +1,12 @@
* Ingenic SoC UART
Required properties:
-- compatible : "ingenic,jz4740-uart", "ingenic,jz4760-uart",
- "ingenic,jz4775-uart" or "ingenic,jz4780-uart"
+- compatible : One of:
+ - "ingenic,jz4740-uart",
+ - "ingenic,jz4760-uart",
+ - "ingenic,jz4770-uart",
+ - "ingenic,jz4775-uart",
+ - "ingenic,jz4780-uart".
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
- clocks : phandles to the module & baud clocks.
diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 6af84900870e..165b4bb3de93 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -125,6 +125,10 @@ EARLYCON_DECLARE(jz4740_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4740_uart, "ingenic,jz4740-uart",
ingenic_early_console_setup);
+EARLYCON_DECLARE(jz4770_uart, ingenic_early_console_setup);
+OF_EARLYCON_DECLARE(jz4770_uart, "ingenic,jz4770-uart",
+ ingenic_early_console_setup);
+
EARLYCON_DECLARE(jz4775_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4775_uart, "ingenic,jz4775-uart",
ingenic_early_console_setup);
@@ -319,6 +323,7 @@ static const struct ingenic_uart_config jz4780_uart_config = {
static const struct of_device_id of_match[] = {
{ .compatible = "ingenic,jz4740-uart", .data = &jz4740_uart_config },
{ .compatible = "ingenic,jz4760-uart", .data = &jz4760_uart_config },
+ { .compatible = "ingenic,jz4770-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4775-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
{ /* sentinel */ }
--
2.15.1
^ permalink raw reply related
* [PATCH 3/3] serial: 8250_ingenic: Parse earlycon options
From: Paul Cercueil @ 2017-12-28 13:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, linux-serial, devicetree, linux-kernel,
Paul Cercueil
In-Reply-To: <20171228130709.12457-1-paul@crapouillou.net>
In the devicetree, it is possible to specify the baudrate, parity,
bits, flow of the early console, by passing a configuration string like
this:
aliases {
serial0 = &uart0;
};
chosen {
stdout-path = "serial0:57600n8";
};
This, for instance, will configure the early console for a baudrate of
57600 bps, no parity, and 8 bits per baud.
This patches implements parsing of this configuration string in the
8250_ingenic driver, which previously just ignored it.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
drivers/tty/serial/8250/8250_ingenic.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
v1: Initial version
diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 165b4bb3de93..15a8c8dfa92b 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -91,14 +91,22 @@ static int __init ingenic_early_console_setup(struct earlycon_device *dev,
const char *opt)
{
struct uart_port *port = &dev->port;
- unsigned int baud, divisor;
+ unsigned int divisor;
+ int baud = 115200;
if (!dev->port.membase)
return -ENODEV;
+ if (opt) {
+ unsigned int parity, bits, flow; /* unused for now */
+
+ uart_parse_options(opt, &baud, &parity, &bits, &flow);
+ }
+
ingenic_early_console_setup_clock(dev);
- baud = dev->baud ?: 115200;
+ if (dev->baud)
+ baud = dev->baud;
divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * baud);
early_out(port, UART_IER, 0);
--
2.15.1
^ permalink raw reply related
* [PATCH v4 00/15] Ingenic JZ4770 and GCW Zero support
From: Paul Cercueil @ 2017-12-28 13:56 UTC (permalink / raw)
To: Ralf Baechle, Rob Herring, Michael Turquette
Cc: Mark Rutland, Stephen Boyd, Maarten ter Huurne, devicetree,
linux-kernel, linux-mips, linux-clk
In-Reply-To: <20170702163016.6714-2-paul@crapouillou.net>
Hi,
This is my v4 of my patch series to support the JZ4770 SoC from Ingenic
as well as the GCW Zero handheld console.
Not much changed since v3, I dropped the three serial-related patches
(07-08-09/18) as I will submit them separately. The only other change is
that I rebased the patch series on top of v4.15-rc5.
Regards,
-Paul Cercueil
^ permalink raw reply
* [PATCH v4 01/15] clk: ingenic: Use const pointer to clk_ops in struct
From: Paul Cercueil @ 2017-12-28 13:56 UTC (permalink / raw)
To: Ralf Baechle, Rob Herring, Michael Turquette
Cc: Mark Rutland, Stephen Boyd, Maarten ter Huurne,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Paul Cercueil
In-Reply-To: <20171228135634.30000-1-paul-icTtO2rgO2OTuSrc4Mpeew@public.gmane.org>
The CGU common code does not modify the pointed clk_ops structure, so it
should be marked as const.
Signed-off-by: Paul Cercueil <paul-icTtO2rgO2OTuSrc4Mpeew@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/clk/ingenic/cgu.h | 2 +-
drivers/clk/ingenic/jz4780-cgu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
v2: New patch in this series
v3: No change
v4: No change
diff --git a/drivers/clk/ingenic/cgu.h b/drivers/clk/ingenic/cgu.h
index e78b586536ea..f1527cf75b3f 100644
--- a/drivers/clk/ingenic/cgu.h
+++ b/drivers/clk/ingenic/cgu.h
@@ -120,7 +120,7 @@ struct ingenic_cgu_gate_info {
* @clk_ops: custom clock operation callbacks
*/
struct ingenic_cgu_custom_info {
- struct clk_ops *clk_ops;
+ const struct clk_ops *clk_ops;
};
/**
diff --git a/drivers/clk/ingenic/jz4780-cgu.c b/drivers/clk/ingenic/jz4780-cgu.c
index ac3585ed8228..6427be117ff1 100644
--- a/drivers/clk/ingenic/jz4780-cgu.c
+++ b/drivers/clk/ingenic/jz4780-cgu.c
@@ -203,7 +203,7 @@ static int jz4780_otg_phy_set_rate(struct clk_hw *hw, unsigned long req_rate,
return 0;
}
-static struct clk_ops jz4780_otg_phy_ops = {
+static const struct clk_ops jz4780_otg_phy_ops = {
.get_parent = jz4780_otg_phy_get_parent,
.set_parent = jz4780_otg_phy_set_parent,
--
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
* [PATCH v4 02/15] clk: ingenic: Fix recalc_rate for clocks with fixed divider
From: Paul Cercueil @ 2017-12-28 13:56 UTC (permalink / raw)
To: Ralf Baechle, Rob Herring, Michael Turquette
Cc: Mark Rutland, Stephen Boyd, Maarten ter Huurne, devicetree,
linux-kernel, linux-mips, linux-clk, Paul Cercueil
In-Reply-To: <20171228135634.30000-1-paul@crapouillou.net>
Previously, the clocks with a fixed divider would report their rate
as being the same as the one of their parent, independently of the
divider in use. This commit fixes this behaviour.
This went unnoticed as neither the jz4740 nor the jz4780 CGU code
have clocks with fixed dividers yet.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
drivers/clk/ingenic/cgu.c | 2 ++
1 file changed, 2 insertions(+)
v2: No changes
v3: No changes
v4: No changes
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index ab393637f7b0..a2e73a6d60fd 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -328,6 +328,8 @@ ingenic_clk_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
div *= clk_info->div.div;
rate /= div;
+ } else if (clk_info->type & CGU_CLK_FIXDIV) {
+ rate /= clk_info->fixdiv.div;
}
return rate;
--
2.11.0
^ permalink raw reply related
* [PATCH v4 03/15] clk: ingenic: support PLLs with no bypass bit
From: Paul Cercueil @ 2017-12-28 13:56 UTC (permalink / raw)
To: Ralf Baechle, Rob Herring, Michael Turquette
Cc: Mark Rutland, Stephen Boyd, Maarten ter Huurne, devicetree,
linux-kernel, linux-mips, linux-clk, Paul Cercueil
In-Reply-To: <20171228135634.30000-1-paul@crapouillou.net>
The second PLL of the JZ4770 does not have a bypass bit.
This commit makes it possible to support it with the current common CGU
code.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
drivers/clk/ingenic/cgu.c | 3 ++-
drivers/clk/ingenic/cgu.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
v2: No change
v3: No change
v4: No change
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index a2e73a6d60fd..381c4a17a1fc 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -100,7 +100,8 @@ ingenic_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
n += pll_info->n_offset;
od_enc = ctl >> pll_info->od_shift;
od_enc &= GENMASK(pll_info->od_bits - 1, 0);
- bypass = !!(ctl & BIT(pll_info->bypass_bit));
+ bypass = !pll_info->no_bypass_bit &&
+ !!(ctl & BIT(pll_info->bypass_bit));
enable = !!(ctl & BIT(pll_info->enable_bit));
if (bypass)
diff --git a/drivers/clk/ingenic/cgu.h b/drivers/clk/ingenic/cgu.h
index f1527cf75b3f..9da34910bd80 100644
--- a/drivers/clk/ingenic/cgu.h
+++ b/drivers/clk/ingenic/cgu.h
@@ -48,6 +48,7 @@
* @bypass_bit: the index of the bypass bit in the PLL control register
* @enable_bit: the index of the enable bit in the PLL control register
* @stable_bit: the index of the stable bit in the PLL control register
+ * @no_bypass_bit: if set, the PLL has no bypass functionality
*/
struct ingenic_cgu_pll_info {
unsigned reg;
@@ -58,6 +59,7 @@ struct ingenic_cgu_pll_info {
u8 bypass_bit;
u8 enable_bit;
u8 stable_bit;
+ bool no_bypass_bit;
};
/**
--
2.11.0
^ permalink raw reply related
* [PATCH v4 04/15] clk: ingenic: Add code to enable/disable PLLs
From: Paul Cercueil @ 2017-12-28 13:56 UTC (permalink / raw)
To: Ralf Baechle, Rob Herring, Michael Turquette
Cc: Mark Rutland, Stephen Boyd, Maarten ter Huurne, devicetree,
linux-kernel, linux-mips, linux-clk, Paul Cercueil
In-Reply-To: <20171228135634.30000-1-paul@crapouillou.net>
This commit permits the PLLs to be dynamically enabled and disabled when
their children clocks are enabled and disabled.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
drivers/clk/ingenic/cgu.c | 89 +++++++++++++++++++++++++++++++++++++++--------
1 file changed, 74 insertions(+), 15 deletions(-)
v2: No change
v3: No change
v4: No change
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index 381c4a17a1fc..56a712c9075f 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -107,9 +107,6 @@ ingenic_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
if (bypass)
return parent_rate;
- if (!enable)
- return 0;
-
for (od = 0; od < pll_info->od_max; od++) {
if (pll_info->od_encoding[od] == od_enc)
break;
@@ -153,17 +150,25 @@ ingenic_pll_calc(const struct ingenic_cgu_clk_info *clk_info,
return div_u64((u64)parent_rate * m, n * od);
}
-static long
-ingenic_pll_round_rate(struct clk_hw *hw, unsigned long req_rate,
- unsigned long *prate)
+static inline const struct ingenic_cgu_clk_info *to_clk_info(
+ struct ingenic_clk *ingenic_clk)
{
- struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
struct ingenic_cgu *cgu = ingenic_clk->cgu;
const struct ingenic_cgu_clk_info *clk_info;
clk_info = &cgu->clock_info[ingenic_clk->idx];
BUG_ON(clk_info->type != CGU_CLK_PLL);
+ return clk_info;
+}
+
+static long
+ingenic_pll_round_rate(struct clk_hw *hw, unsigned long req_rate,
+ unsigned long *prate)
+{
+ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
+ const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk);
+
return ingenic_pll_calc(clk_info, req_rate, *prate, NULL, NULL, NULL);
}
@@ -171,19 +176,14 @@ static int
ingenic_pll_set_rate(struct clk_hw *hw, unsigned long req_rate,
unsigned long parent_rate)
{
- const unsigned timeout = 100;
struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
struct ingenic_cgu *cgu = ingenic_clk->cgu;
- const struct ingenic_cgu_clk_info *clk_info;
- const struct ingenic_cgu_pll_info *pll_info;
+ const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk);
+ const struct ingenic_cgu_pll_info *pll_info = &clk_info->pll;
unsigned long rate, flags;
- unsigned m, n, od, i;
+ unsigned int m, n, od;
u32 ctl;
- clk_info = &cgu->clock_info[ingenic_clk->idx];
- BUG_ON(clk_info->type != CGU_CLK_PLL);
- pll_info = &clk_info->pll;
-
rate = ingenic_pll_calc(clk_info, req_rate, parent_rate,
&m, &n, &od);
if (rate != req_rate)
@@ -202,6 +202,26 @@ ingenic_pll_set_rate(struct clk_hw *hw, unsigned long req_rate,
ctl &= ~(GENMASK(pll_info->od_bits - 1, 0) << pll_info->od_shift);
ctl |= pll_info->od_encoding[od - 1] << pll_info->od_shift;
+ writel(ctl, cgu->base + pll_info->reg);
+ spin_unlock_irqrestore(&cgu->lock, flags);
+
+ return 0;
+}
+
+static int ingenic_pll_enable(struct clk_hw *hw)
+{
+ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
+ struct ingenic_cgu *cgu = ingenic_clk->cgu;
+ const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk);
+ const struct ingenic_cgu_pll_info *pll_info = &clk_info->pll;
+ const unsigned int timeout = 100;
+ unsigned long flags;
+ unsigned int i;
+ u32 ctl;
+
+ spin_lock_irqsave(&cgu->lock, flags);
+ ctl = readl(cgu->base + pll_info->reg);
+
ctl &= ~BIT(pll_info->bypass_bit);
ctl |= BIT(pll_info->enable_bit);
@@ -223,10 +243,48 @@ ingenic_pll_set_rate(struct clk_hw *hw, unsigned long req_rate,
return 0;
}
+static void ingenic_pll_disable(struct clk_hw *hw)
+{
+ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
+ struct ingenic_cgu *cgu = ingenic_clk->cgu;
+ const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk);
+ const struct ingenic_cgu_pll_info *pll_info = &clk_info->pll;
+ unsigned long flags;
+ u32 ctl;
+
+ spin_lock_irqsave(&cgu->lock, flags);
+ ctl = readl(cgu->base + pll_info->reg);
+
+ ctl &= ~BIT(pll_info->enable_bit);
+
+ writel(ctl, cgu->base + pll_info->reg);
+ spin_unlock_irqrestore(&cgu->lock, flags);
+}
+
+static int ingenic_pll_is_enabled(struct clk_hw *hw)
+{
+ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
+ struct ingenic_cgu *cgu = ingenic_clk->cgu;
+ const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk);
+ const struct ingenic_cgu_pll_info *pll_info = &clk_info->pll;
+ unsigned long flags;
+ u32 ctl;
+
+ spin_lock_irqsave(&cgu->lock, flags);
+ ctl = readl(cgu->base + pll_info->reg);
+ spin_unlock_irqrestore(&cgu->lock, flags);
+
+ return !!(ctl & BIT(pll_info->enable_bit));
+}
+
static const struct clk_ops ingenic_pll_ops = {
.recalc_rate = ingenic_pll_recalc_rate,
.round_rate = ingenic_pll_round_rate,
.set_rate = ingenic_pll_set_rate,
+
+ .enable = ingenic_pll_enable,
+ .disable = ingenic_pll_disable,
+ .is_enabled = ingenic_pll_is_enabled,
};
/*
@@ -601,6 +659,7 @@ static int ingenic_register_clock(struct ingenic_cgu *cgu, unsigned idx)
}
} else if (caps & CGU_CLK_PLL) {
clk_init.ops = &ingenic_pll_ops;
+ clk_init.flags |= CLK_SET_RATE_GATE;
caps &= ~CGU_CLK_PLL;
--
2.11.0
^ permalink raw reply related
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