* Re: [PATCH 1/4] dt-bindings: iio/adc: Add a compatible string for JZ4770 SoC ADC
From: Rob Herring @ 2019-07-10 13:52 UTC (permalink / raw)
Cc: Jonathan Cameron, Mark Rutland, linux-iio, devicetree,
linux-kernel, Maarten ter Huurne, Paul Cercueil, Artur Rojek
In-Reply-To: <20190623184732.5492-1-contact@artur-rojek.eu>
On Sun, 23 Jun 2019 20:47:29 +0200, Artur Rojek wrote:
> Add a compatible string for the ADC controller present on
> Ingenic JZ4770 SoC.
>
> Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
> ---
> Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/3] opp: core: add regulators enable and disable
From: Kamil Konieczny @ 2019-07-10 13:52 UTC (permalink / raw)
To: Viresh Kumar
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Chanwoo Choi,
Krzysztof Kozlowski, Kukjin Kim, Kyungmin Park, Mark Rutland,
MyungJoo Ham, Nishanth Menon, Rob Herring, Stephen Boyd,
Viresh Kumar, devicetree, linux-arm-kernel, linux-kernel,
linux-pm, linux-samsung-soc
In-Reply-To: <1795603c-686f-dfb5-5982-c836b36dca9c@partner.samsung.com>
On 10.07.2019 12:43, Kamil Konieczny wrote:
> On 09.07.2019 07:40, Viresh Kumar wrote:
>> On 08-07-19, 16:11, k.konieczny@partner.samsung.com wrote:
>>> From: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>>
>>> Add enable regulators to dev_pm_opp_set_regulators() and disable
>>> regulators to dev_pm_opp_put_regulators(). This prepares for
>>> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
>>>
>>> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>> ---
>>> drivers/opp/core.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>>> index 0e7703fe733f..947cac452854 100644
>>> --- a/drivers/opp/core.c
>>> +++ b/drivers/opp/core.c
>>> @@ -1580,8 +1580,19 @@ struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
>>> if (ret)
>>> goto free_regulators;
>>>
>>> + for (i = 0; i < opp_table->regulator_count; i++) {
>>> + ret = regulator_enable(opp_table->regulators[i]);
>>> + if (ret < 0)
>>> + goto disable;
>>> + }
>>
>> I am wondering on why is this really required as this isn't done for
>> any other platform, probably because the regulators are enabled by
>> bootloader and are always on.
>
> It is not ABI break, it should work with existing DTBs
Sorry, this answer should go to question by Krzysztof
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2 0/2] Add DRM ILI9341 parallel RGB panel driver
From: Sam Ravnborg @ 2019-07-10 13:51 UTC (permalink / raw)
To: Josef Lusticky; +Cc: devicetree, airlied, dri-devel, thierry.reding
In-Reply-To: <20190708145618.26031-1-josef@lusticky.cz>
Hi Josef.
On Mon, Jul 08, 2019 at 04:56:16PM +0200, Josef Lusticky wrote:
> Hi,
> This is the v2 of the patch-set which adds support for
> Ilitek ILI9341 parallel RGB panels.
>
> The ILI9341 chip supports both parallel RGB input mode and SPI input mode.
> This driver adds support for the parallel RGB input mode.
>
> Changes since v1:
> * Device-tree bindings in one file
> * D/C GPIO pin is optional
> * mipi_dbi_* functions used to initialize the display
> * entry in MAINTAINERS sorted alphabetically
> * Makefile, Kconfig: DRM_PANEL_ILITEK_IL9341 renamed to DRM_PANEL_ILITEK_ILI9341
> * Kconfig: depend on BACKLIGHT_CLASS_DEVICE
> * Kconfig: select TINYDRM_MIPI_DBI
> * order of include files changed
> * drm_mode_duplicate checked for failure
Thanks for doing all this.
Some minor details. Please fix and resend so we can these patches
applied.
Please also re-check if you forgot an ack from Rob on the bindings file.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 0/3] add coupled regulators for Exynos5422/5800
From: Kamil Konieczny @ 2019-07-10 13:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Chanwoo Choi,
Kukjin Kim, Kyungmin Park, Mark Rutland, MyungJoo Ham,
Nishanth Menon, Rob Herring, Stephen Boyd, Viresh Kumar,
devicetree, linux-arm-kernel, linux-kernel, linux-pm,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <CAJKOXPc1rOyFujyWk4HwmQb6YEXd=CEHKwN8AH_pKxk-6CA08w@mail.gmail.com>
On 10.07.2019 12:14, Krzysztof Kozlowski wrote:
> On Wed, 10 Jul 2019 at 12:03, Kamil Konieczny
> <k.konieczny@partner.samsung.com> wrote:
>>
>> On 10.07.2019 11:00, Krzysztof Kozlowski wrote:
>>> On Mon, 8 Jul 2019 at 16:12, <k.konieczny@partner.samsung.com> wrote:
>>>>
>>>> From: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>>>
>>>> Hi,
>>>>
>>>> The main purpose of this patch series is to add coupled regulators for
>>>> Exynos5422/5800 to keep constrain on voltage difference between vdd_arm
>>>> and vdd_int to be at most 300mV. In exynos-bus instead of using
>>>> regulator_set_voltage_tol() with default voltage tolerance it should be
>>>> used regulator_set_voltage_triplet() with volatege range, and this is
>>>> already present in opp/core.c code, so it can be reused. While at this,
>>>> move setting regulators into opp/core.
>>>>
>>>> This patchset was tested on Odroid XU3.
>>>>
>>>> The last patch depends on two previous.
>>>
>>> So you break the ABI... I assume that patchset maintains
>>> bisectability. However there is no explanation why ABI break is needed
>>> so this does not look good...
>>
>> Patchset is bisectable, first one is simple and do not depends on others,
>> second depends on first, last depends on first and second.
>>
>> What do you mean by breaking ABI ?
>
> I mean, that Linux kernel stops working with existing DTBs... or am I
> mistaken and there is no problem? Maybe I confused the order...
It is not ABI break, it should work with existing DTBs
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [v4 4/6] dt-bindings: phy: Document the Synopsys MIPI DPHY Rx bindings
From: Rob Herring @ 2019-07-10 13:50 UTC (permalink / raw)
To: Luis de Oliveira
Cc: mchehab@kernel.org, davem@davemloft.net,
gregkh@linuxfoundation.org, Jonathan.Cameron@huawei.com,
nicolas.ferre@microchip.com, paulmck@linux.ibm.com,
mark.rutland@arm.com, kishon@ti.com, devicetree@vger.kernel.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Joao.Pinto@synopsys.com
In-Reply-To: <MN2PR12MB371024C55C5B48A91EECE7A0CBF10@MN2PR12MB3710.namprd12.prod.outlook.com>
On Tue, Jul 9, 2019 at 10:29 AM Luis de Oliveira
<Luis.Oliveira@synopsys.com> wrote:
>
> From: Rob Herring <robh@kernel.org>
> Date: Tue, Jul 09, 2019 at 15:20:00
>
> > On Tue, Jun 11, 2019 at 09:20:53PM +0200, Luis Oliveira wrote:
> > > Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
> > > RX mode.
> > >
> > > Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
> > > ---
> > > Changelog
> > > v3-v4
> > > - @Laurent I know I told you I could remove the snps,dphy-frequency on V3 but
> > > it is really useful for me here. I removed all other the proprietary
> > > properties except this one. Do you still think it must be removed?
> > > - Frequency units @Rob
> >
> > Frequency units means append '-khz' to the property name. That also
> > makes the 'frequency' part redundant, so maybe name it more around what
> > the frequency is. The frequency for what?
> >
> > Rob
> >
>
> This is the D-PHY high speed frequency configuration that corresponds to
> the high speed data transfer of the bus.
> Basically is the transmission speed per lane.
> Do you think I can use "link-frequencies" (present in
> video-interfaces.txt) with one frequency?
Seems reasonable.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext Milbeaut HDMAC bindings
From: Rob Herring @ 2019-07-10 13:48 UTC (permalink / raw)
To: Jassi Brar
Cc: open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Devicetree List,
Linux Kernel Mailing List, Vinod, Mark Rutland, Takao Orito,
Masami Hiramatsu, Kazuhiro Kasai, Jassi Brar
In-Reply-To: <CABb+yY3OsAh3xgX8_vvA7A7mU+FkEj__BQs9CxMvf=eYxRYXyw@mail.gmail.com>
On Tue, Jul 9, 2019 at 10:12 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> On Tue, Jul 9, 2019 at 9:34 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, Jun 12, 2019 at 07:52:37PM -0500, jassisinghbrar@gmail.com wrote:
> > > From: Jassi Brar <jaswinder.singh@linaro.org>
> > >
> > > Document the devicetree bindings for Socionext Milbeaut HDMAC
> > > controller. Controller has upto 8 floating channels, that need
> > > a predefined slave-id to work from a set of slaves.
> > >
> > > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > > ---
> > > .../bindings/dma/milbeaut-m10v-hdmac.txt | 54 +++++++++++++++++++
> > > 1 file changed, 54 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > > new file mode 100644
> > > index 000000000000..a104fcb9e73d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > > @@ -0,0 +1,51 @@
> > > +* Milbeaut AHB DMA Controller
> > > +
> > > +Milbeaut AHB DMA controller has transfer capability bellow.
> > > + - memory to memory transfer
> > > + - device to memory transfer
> > > + - memory to device transfer
> > > +
> > > +Required property:
> > > +- compatible: Should be "socionext,milbeaut-m10v-hdmac"
> > > +- reg: Should contain DMA registers location and length.
> > > +- interrupts: Should contain all of the per-channel DMA interrupts.
> >
> > How many?
> >
> Each channel has an IRQ line. And the number of channels is
> configurable. So instead of having some explicit property like
> 'dma-channels', we infer that from the number of irqs registered.
Yes, I get that. There's still a range that's valid and you need to
define those constraints. If there's a variable number of channels,
then that implies different SoCs which should also mean different
compatible strings.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/panel: Add Ilitek ILI9341 parallel RGB panel driver
From: Sam Ravnborg @ 2019-07-10 13:47 UTC (permalink / raw)
To: Josef Lusticky; +Cc: devicetree, airlied, dri-devel, thierry.reding
In-Reply-To: <20190708145618.26031-3-josef@lusticky.cz>
Hi Josef.
Thanks for updating the driver.
On Mon, Jul 08, 2019 at 04:56:18PM +0200, Josef Lusticky wrote:
> Add driver for Ilitek ILI9341 panels in parallel RGB mode
>
> Signed-off-by: Josef Lusticky <josef@lusticky.cz>
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/spi/spi.h>
> +
> +#include <video/mipi_display.h>
> +
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/tinydrm/mipi-dbi.h>
Good to see drivers that no longer uses drmP.h :-)
> +
> +/* ILI9341 extended register set (Vendor Command Set) */
> +#define ILI9341_IFMODE 0xB0 // clock polarity
> +#define ILI9341_IFCTL 0xF6 // interface conrol
> +#define ILI9341_PGAMCTRL 0xE0 // positive gamma control
> +#define ILI9341_NGAMCTRL 0xE1 // negative gamma control
> +
> +#define ILI9341_MADCTL_MV BIT(5)
> +#define ILI9341_MADCTL_MX BIT(6)
> +#define ILI9341_MADCTL_MY BIT(7)
> +
> +/**
> + * struct ili9341_config - the display specific configuration
> + * @width_mm: physical panel width [mm]
> + * @height_mm: physical panel height [mm]
> + */
> +struct ili9341_config {
> + u32 width_mm;
> + u32 height_mm;
> +};
> +
> +struct ili9341 {
> + struct drm_panel panel;
> + struct mipi_dbi *mipi;
> + const struct ili9341_config *conf;
> +};
> +
> +static inline struct ili9341 *panel_to_ili9341(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ili9341, panel);
> +}
> +
> +static int ili9341_deinit(struct drm_panel *panel, struct ili9341 *ili)
> +{
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_OFF);
> + mipi_dbi_command(ili->mipi, MIPI_DCS_ENTER_SLEEP_MODE);
> + msleep(5);
> + return 0;
> +}
> +
> +static int ili9341_init(struct drm_panel *panel, struct ili9341 *ili)
> +{
> + /* HW / SW Reset display and wait */
> + if (ili->mipi->reset)
> + mipi_dbi_hw_reset(ili->mipi);
> +
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SOFT_RESET);
> + msleep(120);
Consider a usleep_range here - to have the waiting a little more relaxed
in the system.
> +
> + /* Polarity */
> + mipi_dbi_command(ili->mipi, ILI9341_IFMODE, 0xC0);
> +
> + /* Interface control */
> + mipi_dbi_command(ili->mipi, ILI9341_IFCTL, 0x09, 0x01, 0x26);
> +
> + /* Pixel format */
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_18BIT << 4);
> +
> + /* Gamma */
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> + mipi_dbi_command(ili->mipi, ILI9341_PGAMCTRL,
> + 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
> + 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
> + mipi_dbi_command(ili->mipi, ILI9341_NGAMCTRL,
> + 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
> + 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
> +
> + /* Rotation */
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SET_ADDRESS_MODE, ILI9341_MADCTL_MX);
> +
> + /* Exit sleep mode */
> + mipi_dbi_command(ili->mipi, MIPI_DCS_EXIT_SLEEP_MODE);
> + msleep(120);
> +
> + mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_ON);
> +
> + return 0;
> +}
> +
> +static int ili9341_unprepare(struct drm_panel *panel)
> +{
> + struct ili9341 *ili = panel_to_ili9341(panel);
> +
> + return ili9341_deinit(panel, ili);
> +}
> +
> +static int ili9341_prepare(struct drm_panel *panel)
> +{
> + struct ili9341 *ili = panel_to_ili9341(panel);
> + int ret;
> +
> + ret = ili9341_init(panel, ili);
> + if (ret < 0)
> + ili9341_unprepare(panel);
> + return ret;
> +}
> +
> +static int ili9341_enable(struct drm_panel *panel)
> +{
> + struct ili9341 *ili = panel_to_ili9341(panel);
> +
> + return backlight_enable(ili->mipi->backlight);
> +}
> +
> +static int ili9341_disable(struct drm_panel *panel)
> +{
> + struct ili9341 *ili = panel_to_ili9341(panel);
> +
> + return backlight_disable(ili->mipi->backlight);
> +}
> +
> +static const struct drm_display_mode prgb_240x320_mode = {
> + .clock = 6350,
> +
> + .hdisplay = 240,
> + .hsync_start = 240 + 10,
> + .hsync_end = 240 + 10 + 10,
> + .htotal = 240 + 10 + 10 + 20,
> +
> + .vdisplay = 320,
> + .vsync_start = 320 + 4,
> + .vsync_end = 320 + 4 + 2,
> + .vtotal = 320 + 4 + 2 + 2,
> +
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED
> +};
> +
> +static int ili9341_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct ili9341 *ili = panel_to_ili9341(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, &prgb_240x320_mode);
> + if (!mode) {
> + DRM_DEV_ERROR(panel->drm->dev, "bad mode or failed to add mode\n");
> + return -ENOMEM;
> + }
> +
> + drm_mode_set_name(mode);
> +
> + mode->width_mm = ili->conf->width_mm;
> + mode->height_mm = ili->conf->height_mm;
> +
> + connector->display_info.width_mm = mode->width_mm;
> + connector->display_info.height_mm = mode->height_mm;
> + connector->display_info.bus_flags |= DRM_BUS_FLAG_DE_HIGH |
> + DRM_BUS_FLAG_PIXDATA_POSEDGE | DRM_BUS_FLAG_SYNC_NEGEDGE;
> +
> + drm_mode_probed_add(connector, mode);
> +
> + return 1; /* Number of modes */
> +}
> +
> +static const struct drm_panel_funcs ili9341_drm_funcs = {
> + .disable = ili9341_disable,
> + .unprepare = ili9341_unprepare,
> + .prepare = ili9341_prepare,
> + .enable = ili9341_enable,
> + .get_modes = ili9341_get_modes,
> +};
> +
> +static int ili9341_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct ili9341 *ili;
> + struct mipi_dbi *mipi;
> + struct gpio_desc *dc_gpio;
> + int ret;
> +
> + mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
> + if (!mipi)
> + return -ENOMEM;
> +
> + ili = devm_kzalloc(dev, sizeof(*ili), GFP_KERNEL);
> + if (!ili)
> + return -ENOMEM;
> +
> + ili->mipi = mipi;
> +
> + spi_set_drvdata(spi, ili);
> +
> + /*
> + * Every new incarnation of this display must have a unique
> + * data entry for the system in this driver.
> + */
> + ili->conf = of_device_get_match_data(dev);
> + if (!ili->conf) {
> + DRM_DEV_ERROR(dev, "missing device configuration\n");
> + return -ENODEV;
> + }
> +
> + ili->mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ili->mipi->reset)) {
> + DRM_DEV_ERROR(dev, "failed to get gpio 'reset'\n");
> + return PTR_ERR(ili->mipi->reset);
> + }
> +
> + ili->mipi->backlight = devm_of_find_backlight(dev);
> + if (IS_ERR(ili->mipi->backlight)) {
> + DRM_DEV_ERROR(dev, "failed to get backlight\n");
> + return PTR_ERR(ili->mipi->backlight);
> + }
> +
> + dc_gpio = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
> + if (IS_ERR(dc_gpio)) {
> + DRM_DEV_ERROR(dev, "failed to get gpio 'dc'\n");
> + return PTR_ERR(dc_gpio);
> + }
> +
> + ret = mipi_dbi_spi_init(spi, ili->mipi, dc_gpio);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "MIPI-DBI SPI setup failed\n");
> + return ret;
> + }
> +
> + drm_panel_init(&ili->panel);
> + ili->panel.dev = dev;
> + ili->panel.funcs = &ili9341_drm_funcs;
> +
> + return drm_panel_add(&ili->panel);
> +}
> +
> +static int ili9341_remove(struct spi_device *spi)
> +{
> + struct ili9341 *ili = spi_get_drvdata(spi);
> +
> + drm_panel_remove(&ili->panel);
> +
> + ili9341_disable(&ili->panel);
> + ili9341_unprepare(&ili->panel);
> +
> + return 0;
> +}
> +
> +static const struct ili9341_config dt024ctft_data = {
> + .width_mm = 37,
> + .height_mm = 49,
> +};
> +
> +static const struct of_device_id ili9341_of_match[] = {
> + { .compatible = "displaytech,dt024ctft", .data = &dt024ctft_data },
> + { /* sentinel */ }
> +};
If another display is supported then the drm_display_mode may not match.
So the above may not prove enough in the future.
for now it should be fine.
> +MODULE_DEVICE_TABLE(of, ili9341_of_match);
> +
> +static struct spi_driver ili9341_driver = {
> + .probe = ili9341_probe,
> + .remove = ili9341_remove,
> + .driver = {
> + .name = "panel-ilitek-ili9341",
> + .of_match_table = ili9341_of_match,
> + },
> +};
> +module_spi_driver(ili9341_driver);
> +
> +MODULE_AUTHOR("Josef Lusticky <josef@lusticky.cz>");
> +MODULE_DESCRIPTION("ILI9341 LCD panel driver");
> +MODULE_LICENSE("GPL");
Looks good.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v7 6/6] arm64: dts: marvell: Add cpu clock node on Armada 7K/8K
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
Add cpu clock node on AP
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 4 ++++
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
index 2baafe12ebd4..472211159979 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
@@ -20,24 +20,28 @@
compatible = "arm,cortex-a72";
reg = <0x000>;
enable-method = "psci";
+ clocks = <&cpu_clk 0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a72";
reg = <0x001>;
enable-method = "psci";
+ clocks = <&cpu_clk 0>;
};
cpu2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a72";
reg = <0x100>;
enable-method = "psci";
+ clocks = <&cpu_clk 1>;
};
cpu3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a72";
reg = <0x101>;
enable-method = "psci";
+ clocks = <&cpu_clk 1>;
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 91dad7e4ee59..fca6536494b3 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -280,6 +280,13 @@
#address-cells = <1>;
#size-cells = <1>;
+ cpu_clk: clock-cpu@278 {
+ compatible = "marvell,ap806-cpu-clock";
+ clocks = <&ap_clk 0>, <&ap_clk 1>;
+ #clock-cells = <1>;
+ reg = <0x278 0xa30>;
+ };
+
ap_thermal: thermal-sensor@80 {
compatible = "marvell,armada-ap806-thermal";
reg = <0x80 0x10>;
--
2.20.1
^ permalink raw reply related
* [PATCH v7 5/6] arm64: marvell: enable the Armada 7K/8K CPU clk driver
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
This commit makes sure the driver for the Armada 7K/8K CPU clock is
enabled.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 42eca656faa8..3cf5769fd17d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -138,6 +138,7 @@ config ARCH_MESON
config ARCH_MVEBU
bool "Marvell EBU SoC Family"
+ select ARMADA_AP_CPU_CLK
select ARMADA_AP806_SYSCON
select ARMADA_CP110_SYSCON
select ARMADA_37XX_CLK
--
2.20.1
^ permalink raw reply related
* [PATCH v7 4/6] clk: mvebu: ap806: Fix clock name for the cluster
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
Actually, the clocks exposed for the cluster are not the CPU clocks, but
the PLL clock used as entry clock for the CPU clocks. The CPU clock will
be managed by a driver submitting in the following patches.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/clk/mvebu/ap806-system-controller.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/ap806-system-controller.c b/drivers/clk/mvebu/ap806-system-controller.c
index 0a58824ff053..73ba8fd7860f 100644
--- a/drivers/clk/mvebu/ap806-system-controller.c
+++ b/drivers/clk/mvebu/ap806-system-controller.c
@@ -97,7 +97,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
cpuclk_freq *= 1000 * 1000;
/* CPU clocks depend on the Sample At Reset configuration */
- name = ap_cp_unique_name(dev, syscon_node, "cpu-cluster-0");
+ name = ap_cp_unique_name(dev, syscon_node, "pll-cluster-0");
ap806_clks[0] = clk_register_fixed_rate(dev, name, NULL,
0, cpuclk_freq);
if (IS_ERR(ap806_clks[0])) {
@@ -105,7 +105,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
goto fail0;
}
- name = ap_cp_unique_name(dev, syscon_node, "cpu-cluster-1");
+ name = ap_cp_unique_name(dev, syscon_node, "pll-cluster-1");
ap806_clks[1] = clk_register_fixed_rate(dev, name, NULL, 0,
cpuclk_freq);
if (IS_ERR(ap806_clks[1])) {
--
2.20.1
^ permalink raw reply related
* [PATCH v7 3/6] clk: mvebu: add CPU clock driver for Armada 7K/8K
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
The CPU frequency is managed at the AP level for the Armada 7K/8K. The
CPU frequency is modified by cluster: the CPUs of the same cluster have
the same frequency.
This patch adds the clock driver that will be used by CPUFreq, it is
based on the work of Omri Itach <omrii@marvell.com>.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/clk/mvebu/Kconfig | 3 +
drivers/clk/mvebu/Makefile | 1 +
drivers/clk/mvebu/ap-cpu-clk.c | 259 +++++++++++++++++++++++++++++++++
3 files changed, 263 insertions(+)
create mode 100644 drivers/clk/mvebu/ap-cpu-clk.c
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 5492fae3f0ab..9d0b2f7cee21 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -39,6 +39,9 @@ config ARMADA_AP806_SYSCON
bool
select ARMADA_AP_CP_HELPER
+config ARMADA_AP_CPU_CLK
+ bool
+
config ARMADA_CP110_SYSCON
bool
select ARMADA_AP_CP_HELPER
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 6638ad962ec1..04464cef0f06 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ARMADA_37XX_CLK) += armada-37xx-tbg.o
obj-$(CONFIG_ARMADA_37XX_CLK) += armada-37xx-periph.o
obj-$(CONFIG_ARMADA_XP_CLK) += armada-xp.o mv98dx3236.o
obj-$(CONFIG_ARMADA_AP806_SYSCON) += ap806-system-controller.o
+obj-$(CONFIG_ARMADA_AP_CPU_CLK) += ap-cpu-clk.o
obj-$(CONFIG_ARMADA_CP110_SYSCON) += cp110-system-controller.o
obj-$(CONFIG_DOVE_CLK) += dove.o dove-divider.o
obj-$(CONFIG_KIRKWOOD_CLK) += kirkwood.o
diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
new file mode 100644
index 000000000000..e4cecb456884
--- /dev/null
+++ b/drivers/clk/mvebu/ap-cpu-clk.c
@@ -0,0 +1,259 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Marvell Armada AP CPU Clock Controller
+ *
+ * Copyright (C) 2018 Marvell
+ *
+ * Omri Itach <omrii@marvell.com>
+ * Gregory Clement <gregory.clement@bootlin.com>
+ */
+
+#define pr_fmt(fmt) "ap-cpu-clk: " fmt
+
+#include <linux/clk-provider.h>
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include "armada_ap_cp_helper.h"
+
+#define AP806_CPU_CLUSTER0 0
+#define AP806_CPU_CLUSTER1 1
+#define AP806_CPUS_PER_CLUSTER 2
+#define APN806_CPU1_MASK 0x1
+
+#define APN806_CLUSTER_NUM_OFFSET 8
+#define APN806_CLUSTER_NUM_MASK BIT(APN806_CLUSTER_NUM_OFFSET)
+
+#define APN806_MAX_DIVIDER 32
+
+/* AP806 CPU DFS register mapping*/
+#define AP806_CA72MP2_0_PLL_CR_0_REG_OFFSET 0x278
+#define AP806_CA72MP2_0_PLL_CR_1_REG_OFFSET 0x280
+#define AP806_CA72MP2_0_PLL_CR_2_REG_OFFSET 0x284
+#define AP806_CA72MP2_0_PLL_SR_REG_OFFSET 0xC94
+
+#define AP806_CA72MP2_0_PLL_CR_CLUSTER_OFFSET 0x14
+#define AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_OFFSET 0
+#define AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_MASK \
+ (0x3f << AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_OFFSET)
+#define AP806_PLL_CR_0_CPU_CLK_RELOAD_FORCE_OFFSET 24
+#define AP806_PLL_CR_0_CPU_CLK_RELOAD_FORCE_MASK \
+ (0x1 << AP806_PLL_CR_0_CPU_CLK_RELOAD_FORCE_OFFSET)
+#define AP806_PLL_CR_0_CPU_CLK_RELOAD_RATIO_OFFSET 16
+#define AP806_CA72MP2_0_PLL_RATIO_STATE 11
+
+#define STATUS_POLL_PERIOD_US 1
+#define STATUS_POLL_TIMEOUT_US 1000000
+
+#define to_ap_cpu_clk(_hw) container_of(_hw, struct ap_cpu_clk, hw)
+
+/*
+ * struct ap806_clk: CPU cluster clock controller instance
+ * @cluster: Cluster clock controller index
+ * @clk_name: Cluster clock controller name
+ * @dev : Cluster clock device
+ * @hw: HW specific structure of Cluster clock controller
+ * @pll_cr_base: CA72MP2 Register base (Device Sample at Reset register)
+ */
+struct ap_cpu_clk {
+ unsigned int cluster;
+ const char *clk_name;
+ struct device *dev;
+ struct clk_hw hw;
+ struct regmap *pll_cr_base;
+};
+
+static unsigned long ap_cpu_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct ap_cpu_clk *clk = to_ap_cpu_clk(hw);
+ unsigned int cpu_clkdiv_reg;
+ int cpu_clkdiv_ratio;
+
+ cpu_clkdiv_reg = AP806_CA72MP2_0_PLL_CR_0_REG_OFFSET +
+ (clk->cluster * AP806_CA72MP2_0_PLL_CR_CLUSTER_OFFSET);
+ regmap_read(clk->pll_cr_base, cpu_clkdiv_reg, &cpu_clkdiv_ratio);
+ cpu_clkdiv_ratio &= AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_MASK;
+ cpu_clkdiv_ratio >>= AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_OFFSET;
+
+ return parent_rate / cpu_clkdiv_ratio;
+}
+
+static int ap_cpu_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct ap_cpu_clk *clk = to_ap_cpu_clk(hw);
+ int ret, reg, divider = parent_rate / rate;
+ unsigned int cpu_clkdiv_reg, cpu_force_reg, cpu_ratio_reg, stable_bit;
+
+ cpu_clkdiv_reg = AP806_CA72MP2_0_PLL_CR_0_REG_OFFSET +
+ (clk->cluster * AP806_CA72MP2_0_PLL_CR_CLUSTER_OFFSET);
+ cpu_force_reg = AP806_CA72MP2_0_PLL_CR_1_REG_OFFSET +
+ (clk->cluster * AP806_CA72MP2_0_PLL_CR_CLUSTER_OFFSET);
+ cpu_ratio_reg = AP806_CA72MP2_0_PLL_CR_2_REG_OFFSET +
+ (clk->cluster * AP806_CA72MP2_0_PLL_CR_CLUSTER_OFFSET);
+
+ regmap_update_bits(clk->pll_cr_base, cpu_clkdiv_reg,
+ AP806_PLL_CR_0_CPU_CLK_DIV_RATIO_MASK, divider);
+
+ regmap_update_bits(clk->pll_cr_base, cpu_force_reg,
+ AP806_PLL_CR_0_CPU_CLK_RELOAD_FORCE_MASK,
+ AP806_PLL_CR_0_CPU_CLK_RELOAD_FORCE_MASK);
+
+ regmap_update_bits(clk->pll_cr_base, cpu_ratio_reg,
+ BIT(AP806_PLL_CR_0_CPU_CLK_RELOAD_RATIO_OFFSET),
+ BIT(AP806_PLL_CR_0_CPU_CLK_RELOAD_RATIO_OFFSET));
+
+ stable_bit = BIT(clk->cluster * AP806_CA72MP2_0_PLL_RATIO_STATE),
+
+ ret = regmap_read_poll_timeout(clk->pll_cr_base,
+ AP806_CA72MP2_0_PLL_SR_REG_OFFSET, reg,
+ reg & stable_bit, STATUS_POLL_PERIOD_US,
+ STATUS_POLL_TIMEOUT_US);
+ if (ret)
+ return ret;
+
+ regmap_update_bits(clk->pll_cr_base, cpu_ratio_reg,
+ BIT(AP806_PLL_CR_0_CPU_CLK_RELOAD_RATIO_OFFSET), 0);
+
+ return 0;
+}
+
+static long ap_cpu_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ int divider = *parent_rate / rate;
+
+ divider = min(divider, APN806_MAX_DIVIDER);
+
+ return *parent_rate / divider;
+}
+
+static const struct clk_ops ap_cpu_clk_ops = {
+ .recalc_rate = ap_cpu_clk_recalc_rate,
+ .round_rate = ap_cpu_clk_round_rate,
+ .set_rate = ap_cpu_clk_set_rate,
+};
+
+static int ap_cpu_clock_probe(struct platform_device *pdev)
+{
+ int ret, nclusters = 0, cluster_index = 0;
+ struct device *dev = &pdev->dev;
+ struct device_node *dn, *np = dev->of_node;
+ struct clk_hw_onecell_data *ap_cpu_data;
+ struct ap_cpu_clk *ap_cpu_clk;
+ struct regmap *regmap;
+
+ regmap = syscon_node_to_regmap(np->parent);
+ if (IS_ERR(regmap)) {
+ pr_err("cannot get pll_cr_base regmap\n");
+ return PTR_ERR(regmap);
+ }
+
+ /*
+ * AP806 has 4 cpus and DFS for AP806 is controlled per
+ * cluster (2 CPUs per cluster), cpu0 and cpu1 are fixed to
+ * cluster0 while cpu2 and cpu3 are fixed to cluster1 whether
+ * they are enabled or not. Since cpu0 is the boot cpu, then
+ * cluster0 must exist. If cpu2 or cpu3 is enabled, cluster1
+ * will exist and the cluster number is 2; otherwise the
+ * cluster number is 1.
+ */
+ nclusters = 1;
+ for_each_of_cpu_node(dn) {
+ int cpu, err;
+
+ err = of_property_read_u32(dn, "reg", &cpu);
+ if (WARN_ON(err))
+ return err;
+
+ /* If cpu2 or cpu3 is enabled */
+ if (cpu & APN806_CLUSTER_NUM_MASK) {
+ nclusters = 2;
+ break;
+ }
+ }
+ /*
+ * DFS for AP806 is controlled per cluster (2 CPUs per cluster),
+ * so allocate structs per cluster
+ */
+ ap_cpu_clk = devm_kcalloc(dev, nclusters, sizeof(*ap_cpu_clk),
+ GFP_KERNEL);
+ if (!ap_cpu_clk)
+ return -ENOMEM;
+
+ ap_cpu_data = devm_kzalloc(dev, sizeof(*ap_cpu_data) +
+ sizeof(struct clk_hw *) * nclusters,
+ GFP_KERNEL);
+ if (!ap_cpu_data)
+ return -ENOMEM;
+
+ for_each_of_cpu_node(dn) {
+ char *clk_name = "cpu-cluster-0";
+ struct clk_init_data init;
+ const char *parent_name;
+ struct clk *parent;
+ int cpu, err;
+
+ err = of_property_read_u32(dn, "reg", &cpu);
+ if (WARN_ON(err))
+ return err;
+
+ cluster_index = cpu & APN806_CLUSTER_NUM_MASK;
+ cluster_index >>= APN806_CLUSTER_NUM_OFFSET;
+
+ /* Initialize once for one cluster */
+ if (ap_cpu_data->hws[cluster_index])
+ continue;
+
+ parent = of_clk_get(np, cluster_index);
+ if (IS_ERR(parent)) {
+ dev_err(dev, "Could not get the clock parent\n");
+ return -EINVAL;
+ }
+ parent_name = __clk_get_name(parent);
+ clk_name[12] += cluster_index;
+ ap_cpu_clk[cluster_index].clk_name =
+ ap_cp_unique_name(dev, np->parent, clk_name);
+ ap_cpu_clk[cluster_index].cluster = cluster_index;
+ ap_cpu_clk[cluster_index].pll_cr_base = regmap;
+ ap_cpu_clk[cluster_index].hw.init = &init;
+ ap_cpu_clk[cluster_index].dev = dev;
+
+ init.name = ap_cpu_clk[cluster_index].clk_name;
+ init.ops = &ap_cpu_clk_ops;
+ init.num_parents = 1;
+ init.parent_names = &parent_name;
+
+ ret = devm_clk_hw_register(dev, &ap_cpu_clk[cluster_index].hw);
+ if (ret)
+ return ret;
+ ap_cpu_data->hws[cluster_index] = &ap_cpu_clk[cluster_index].hw;
+ }
+
+ ap_cpu_data->num = cluster_index + 1;
+
+ ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get, ap_cpu_data);
+ if (ret)
+ dev_err(dev, "failed to register OF clock provider\n");
+
+ return ret;
+}
+
+static const struct of_device_id ap_cpu_clock_of_match[] = {
+ { .compatible = "marvell,ap806-cpu-clock", },
+ { }
+};
+
+static struct platform_driver ap_cpu_clock_driver = {
+ .probe = ap_cpu_clock_probe,
+ .driver = {
+ .name = "marvell-ap-cpu-clock",
+ .of_match_table = ap_cpu_clock_of_match,
+ .suppress_bind_attrs = true,
+ },
+};
+builtin_platform_driver(ap_cpu_clock_driver);
--
2.20.1
^ permalink raw reply related
* [PATCH v7 2/6] clk: mvebu: add helper file for Armada AP and CP clocks
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
Clock drivers for Armada AP and Armada CP use the same function to
generate unique clock name. A third drivers is coming with the same
need, so it's time to move this function in a common file.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/clk/mvebu/Kconfig | 5 ++++
drivers/clk/mvebu/Makefile | 1 +
drivers/clk/mvebu/ap806-system-controller.c | 24 ++++------------
drivers/clk/mvebu/armada_ap_cp_helper.c | 30 +++++++++++++++++++
drivers/clk/mvebu/armada_ap_cp_helper.h | 11 +++++++
drivers/clk/mvebu/cp110-system-controller.c | 32 ++++++---------------
6 files changed, 61 insertions(+), 42 deletions(-)
create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.c
create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.h
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index fddc8ac5faff..5492fae3f0ab 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -7,6 +7,9 @@ config MVEBU_CLK_CPU
config MVEBU_CLK_COREDIV
bool
+config ARMADA_AP_CP_HELPER
+ bool
+
config ARMADA_370_CLK
bool
select MVEBU_CLK_COMMON
@@ -34,9 +37,11 @@ config ARMADA_XP_CLK
config ARMADA_AP806_SYSCON
bool
+ select ARMADA_AP_CP_HELPER
config ARMADA_CP110_SYSCON
bool
+ select ARMADA_AP_CP_HELPER
config DOVE_CLK
bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 93ac3685271f..6638ad962ec1 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_MVEBU_CLK_COMMON) += common.o
obj-$(CONFIG_MVEBU_CLK_CPU) += clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_COREDIV) += clk-corediv.o
+obj-$(CONFIG_ARMADA_AP_CP_HELPER) += armada_ap_cp_helper.o
obj-$(CONFIG_ARMADA_370_CLK) += armada-370.o
obj-$(CONFIG_ARMADA_375_CLK) += armada-375.o
diff --git a/drivers/clk/mvebu/ap806-system-controller.c b/drivers/clk/mvebu/ap806-system-controller.c
index ea54a874bbda..0a58824ff053 100644
--- a/drivers/clk/mvebu/ap806-system-controller.c
+++ b/drivers/clk/mvebu/ap806-system-controller.c
@@ -10,11 +10,11 @@
#define pr_fmt(fmt) "ap806-system-controller: " fmt
+#include "armada_ap_cp_helper.h"
#include <linux/clk-provider.h>
#include <linux/mfd/syscon.h>
#include <linux/init.h>
#include <linux/of.h>
-#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -30,18 +30,6 @@ static struct clk_onecell_data ap806_clk_data = {
.clk_num = AP806_CLK_NUM,
};
-static char *ap806_unique_name(struct device *dev, struct device_node *np,
- char *name)
-{
- const __be32 *reg;
- u64 addr;
-
- reg = of_get_property(np, "reg", NULL);
- addr = of_translate_address(np, reg);
- return devm_kasprintf(dev, GFP_KERNEL, "%llx-%s",
- (unsigned long long)addr, name);
-}
-
static int ap806_syscon_common_probe(struct platform_device *pdev,
struct device_node *syscon_node)
{
@@ -109,7 +97,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
cpuclk_freq *= 1000 * 1000;
/* CPU clocks depend on the Sample At Reset configuration */
- name = ap806_unique_name(dev, syscon_node, "cpu-cluster-0");
+ name = ap_cp_unique_name(dev, syscon_node, "cpu-cluster-0");
ap806_clks[0] = clk_register_fixed_rate(dev, name, NULL,
0, cpuclk_freq);
if (IS_ERR(ap806_clks[0])) {
@@ -117,7 +105,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
goto fail0;
}
- name = ap806_unique_name(dev, syscon_node, "cpu-cluster-1");
+ name = ap_cp_unique_name(dev, syscon_node, "cpu-cluster-1");
ap806_clks[1] = clk_register_fixed_rate(dev, name, NULL, 0,
cpuclk_freq);
if (IS_ERR(ap806_clks[1])) {
@@ -126,7 +114,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
}
/* Fixed clock is always 1200 Mhz */
- fixedclk_name = ap806_unique_name(dev, syscon_node, "fixed");
+ fixedclk_name = ap_cp_unique_name(dev, syscon_node, "fixed");
ap806_clks[2] = clk_register_fixed_rate(dev, fixedclk_name, NULL,
0, 1200 * 1000 * 1000);
if (IS_ERR(ap806_clks[2])) {
@@ -135,7 +123,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
}
/* MSS Clock is fixed clock divided by 6 */
- name = ap806_unique_name(dev, syscon_node, "mss");
+ name = ap_cp_unique_name(dev, syscon_node, "mss");
ap806_clks[3] = clk_register_fixed_factor(NULL, name, fixedclk_name,
0, 1, 6);
if (IS_ERR(ap806_clks[3])) {
@@ -144,7 +132,7 @@ static int ap806_syscon_common_probe(struct platform_device *pdev,
}
/* SDIO(/eMMC) Clock is fixed clock divided by 3 */
- name = ap806_unique_name(dev, syscon_node, "sdio");
+ name = ap_cp_unique_name(dev, syscon_node, "sdio");
ap806_clks[4] = clk_register_fixed_factor(NULL, name,
fixedclk_name,
0, 1, 3);
diff --git a/drivers/clk/mvebu/armada_ap_cp_helper.c b/drivers/clk/mvebu/armada_ap_cp_helper.c
new file mode 100644
index 000000000000..6a930f697ee5
--- /dev/null
+++ b/drivers/clk/mvebu/armada_ap_cp_helper.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Marvell Armada AP and CP110 helper
+ *
+ * Copyright (C) 2018 Marvell
+ *
+ * Gregory Clement <gregory.clement@bootlin.com>
+ *
+ */
+
+#include "armada_ap_cp_helper.h"
+#include <linux/device.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+char *ap_cp_unique_name(struct device *dev, struct device_node *np,
+ const char *name)
+{
+ const __be32 *reg;
+ u64 addr;
+
+ /* Do not create a name if there is no clock */
+ if (!name)
+ return NULL;
+
+ reg = of_get_property(np, "reg", NULL);
+ addr = of_translate_address(np, reg);
+ return devm_kasprintf(dev, GFP_KERNEL, "%llx-%s",
+ (unsigned long long)addr, name);
+}
diff --git a/drivers/clk/mvebu/armada_ap_cp_helper.h b/drivers/clk/mvebu/armada_ap_cp_helper.h
new file mode 100644
index 000000000000..810af1e5dfa4
--- /dev/null
+++ b/drivers/clk/mvebu/armada_ap_cp_helper.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __ARMADA_AP_CP_HELPER_H
+#define __ARMADA_AP_CP_HELPER_H
+
+struct device;
+struct device_node;
+
+char *ap_cp_unique_name(struct device *dev, struct device_node *np,
+ const char *name);
+#endif
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index b6de283f45e3..808463276145 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -26,11 +26,11 @@
#define pr_fmt(fmt) "cp110-system-controller: " fmt
+#include "armada_ap_cp_helper.h"
#include <linux/clk-provider.h>
#include <linux/mfd/syscon.h>
#include <linux/init.h>
#include <linux/of.h>
-#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/slab.h>
@@ -212,22 +212,6 @@ static struct clk_hw *cp110_of_clk_get(struct of_phandle_args *clkspec,
return ERR_PTR(-EINVAL);
}
-static char *cp110_unique_name(struct device *dev, struct device_node *np,
- const char *name)
-{
- const __be32 *reg;
- u64 addr;
-
- /* Do not create a name if there is no clock */
- if (!name)
- return NULL;
-
- reg = of_get_property(np, "reg", NULL);
- addr = of_translate_address(np, reg);
- return devm_kasprintf(dev, GFP_KERNEL, "%llx-%s",
- (unsigned long long)addr, name);
-}
-
static int cp110_syscon_common_probe(struct platform_device *pdev,
struct device_node *syscon_node)
{
@@ -261,7 +245,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clk_data->num = CP110_CLK_NUM;
/* Register the PLL0 which is the root of the hw tree */
- pll0_name = cp110_unique_name(dev, syscon_node, "pll0");
+ pll0_name = ap_cp_unique_name(dev, syscon_node, "pll0");
hw = clk_hw_register_fixed_rate(NULL, pll0_name, NULL, 0,
1000 * 1000 * 1000);
if (IS_ERR(hw)) {
@@ -272,7 +256,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clks[CP110_CORE_PLL0] = hw;
/* PPv2 is PLL0/3 */
- ppv2_name = cp110_unique_name(dev, syscon_node, "ppv2-core");
+ ppv2_name = ap_cp_unique_name(dev, syscon_node, "ppv2-core");
hw = clk_hw_register_fixed_factor(NULL, ppv2_name, pll0_name, 0, 1, 3);
if (IS_ERR(hw)) {
ret = PTR_ERR(hw);
@@ -282,7 +266,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clks[CP110_CORE_PPV2] = hw;
/* X2CORE clock is PLL0/2 */
- x2core_name = cp110_unique_name(dev, syscon_node, "x2core");
+ x2core_name = ap_cp_unique_name(dev, syscon_node, "x2core");
hw = clk_hw_register_fixed_factor(NULL, x2core_name, pll0_name,
0, 1, 2);
if (IS_ERR(hw)) {
@@ -293,7 +277,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clks[CP110_CORE_X2CORE] = hw;
/* Core clock is X2CORE/2 */
- core_name = cp110_unique_name(dev, syscon_node, "core");
+ core_name = ap_cp_unique_name(dev, syscon_node, "core");
hw = clk_hw_register_fixed_factor(NULL, core_name, x2core_name,
0, 1, 2);
if (IS_ERR(hw)) {
@@ -303,7 +287,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clks[CP110_CORE_CORE] = hw;
/* NAND can be either PLL0/2.5 or core clock */
- nand_name = cp110_unique_name(dev, syscon_node, "nand-core");
+ nand_name = ap_cp_unique_name(dev, syscon_node, "nand-core");
if (nand_clk_ctrl & NF_CLOCK_SEL_400_MASK)
hw = clk_hw_register_fixed_factor(NULL, nand_name,
pll0_name, 0, 2, 5);
@@ -318,7 +302,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
cp110_clks[CP110_CORE_NAND] = hw;
/* SDIO clock is PLL0/2.5 */
- sdio_name = cp110_unique_name(dev, syscon_node, "sdio-core");
+ sdio_name = ap_cp_unique_name(dev, syscon_node, "sdio-core");
hw = clk_hw_register_fixed_factor(NULL, sdio_name,
pll0_name, 0, 2, 5);
if (IS_ERR(hw)) {
@@ -330,7 +314,7 @@ static int cp110_syscon_common_probe(struct platform_device *pdev,
/* create the unique name for all the gate clocks */
for (i = 0; i < ARRAY_SIZE(gate_base_names); i++)
- gate_name[i] = cp110_unique_name(dev, syscon_node,
+ gate_name[i] = ap_cp_unique_name(dev, syscon_node,
gate_base_names[i]);
for (i = 0; i < ARRAY_SIZE(gate_base_names); i++) {
--
2.20.1
^ permalink raw reply related
* [PATCH v7 1/6] dt-bindings: ap806: add the cluster clock node in the syscon file
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
In-Reply-To: <20190710134346.30239-1-gregory.clement@bootlin.com>
Document the device tree binding for the cluster clock controllers found
in the Armada 7K/8K SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
.../arm/marvell/ap806-system-controller.txt | 31 +++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
index 7b8b8eb0191f..4f21c1024073 100644
--- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
@@ -21,8 +21,8 @@ Clocks:
The Device Tree node representing the AP806 system controller provides
a number of clocks:
- - 0: clock of CPU cluster 0
- - 1: clock of CPU cluster 1
+ - 0: reference clock of CPU cluster 0
+ - 1: reference clock of CPU cluster 1
- 2: fixed PLL at 1200 Mhz
- 3: MSS clock, derived from the fixed PLL
@@ -143,3 +143,30 @@ ap_syscon1: system-controller@6f8000 {
#thermal-sensor-cells = <1>;
};
};
+
+Cluster clocks:
+---------------
+
+Device Tree Clock bindings for cluster clock of AP806 Marvell. Each
+cluster contain up to 2 CPUs running at the same frequency.
+
+Required properties:
+- compatible: must be "marvell,ap806-cpu-clock";
+- #clock-cells : should be set to 1.
+
+- clocks : shall be the input parent clock(s) phandle for the clock
+ (one per cluster)
+
+- reg: register range associated with the cluster clocks
+
+ap_syscon1: system-controller@6f8000 {
+ compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
+ reg = <0x6f8000 0x1000>;
+
+ cpu_clk: clock-cpu@278 {
+ compatible = "marvell,ap806-cpu-clock";
+ clocks = <&ap_clk 0>, <&ap_clk 1>;
+ #clock-cells = <1>;
+ reg = <0x278 0xa30>;
+ };
+};
--
2.20.1
^ permalink raw reply related
* [PATCH v7 0/6] Add CPU clock support for Armada 7K/8K
From: Gregory CLEMENT @ 2019-07-10 13:43 UTC (permalink / raw)
To: Stephen Boyd, Mike Turquette, linux-clk, linux-kernel
Cc: Rob Herring, devicetree, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Maxime Chevallier
Hello,
This is the seventh version of a series allowing to manage the cpu
clock for Armada 7K/8K.
For these SoCs, the CPUs share the same clock by cluster, so actually
the clock management is done at cluster level.
As for the other Armada 7K/8K clocks it is possible to have multiple
AP so here again we need to have unique name: the purpose of the second
patch is to share a common code which will be used in 3 drivers.
The last 2 patch enable the driver at dt and platform level and will
be applied through the mvebu subsystem.
Changelog v6->v7:
- Update binding documentation for the AP clock to mention that
they expose reference clocks for the cluster to make distinction
with the cluster clocks themselves exposed by the cpu clock.
- Add precision on the number of parent clock in the binding
documentation.
- Also fix the example by using the reg address in the node name.
Changelog v5->v6:
- Restraint the reg property for the child node to not overlap the
other node.
- Give a specific compatible to ap_syscon1.
Changelog v4->v5:
- As requested by the device tree maintainer make the reg property
mandatory
- Updated the device tree files accordingly with the new binding
Changelog v3->v4:
- Rebased on v5.1-rc1
- Mention in the binding that a reg property can be used to make the
device tree maintainer happy in the hope that there will be finally
a review on this patch blocking the whole series.
Changelog v2->v3:
- Add back the first patch documenting the binding
Changelog v1->v2:
- Header cleanup
- Use unsigned int instead of it for cluster member of the ap_cpu_clk struct
- Use clk_hw instead of clk
- Use regmap_read_poll_timeout
- Use for_each_of_cpu_node
- Remove unnecessary WARN_ON()
- Remove headers from armada_ap_cp_helper.h
- Few other minor cleanup
Gregory CLEMENT (6):
dt-bindings: ap806: add the cluster clock node in the syscon file
clk: mvebu: add helper file for Armada AP and CP clocks
clk: mvebu: add CPU clock driver for Armada 7K/8K
clk: mvebu: ap806: Fix clock name for the cluster
arm64: marvell: enable the Armada 7K/8K CPU clk driver
arm64: dts: marvell: Add cpu clock node on Armada 7K/8K
.../arm/marvell/ap806-system-controller.txt | 31 ++-
arch/arm64/Kconfig.platforms | 1 +
.../boot/dts/marvell/armada-ap806-quad.dtsi | 4 +
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 7 +
drivers/clk/mvebu/Kconfig | 8 +
drivers/clk/mvebu/Makefile | 2 +
drivers/clk/mvebu/ap-cpu-clk.c | 259 ++++++++++++++++++
drivers/clk/mvebu/ap806-system-controller.c | 24 +-
drivers/clk/mvebu/armada_ap_cp_helper.c | 30 ++
drivers/clk/mvebu/armada_ap_cp_helper.h | 11 +
drivers/clk/mvebu/cp110-system-controller.c | 32 +--
11 files changed, 365 insertions(+), 44 deletions(-)
create mode 100644 drivers/clk/mvebu/ap-cpu-clk.c
create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.c
create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.h
--
2.20.1
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: panel: Add parallel RGB mode for Ilitek ILI9341 panels
From: Sam Ravnborg @ 2019-07-10 13:39 UTC (permalink / raw)
To: Josef Lusticky; +Cc: devicetree, airlied, dri-devel, thierry.reding
In-Reply-To: <20190708145618.26031-2-josef@lusticky.cz>
Hi Josef.
On Mon, Jul 08, 2019 at 04:56:17PM +0200, Josef Lusticky wrote:
> ILI9341 supports both SPI input mode and parallel RGB input mode.
> This commit adds parallel RGB input mode bindings.
>
> Signed-off-by: Josef Lusticky <josef@lusticky.cz>
> ---
> .../bindings/display/ilitek,ili9341.txt | 67 ++++++++++++++++---
> 1 file changed, 56 insertions(+), 11 deletions(-)
With Robs patches landed in drm-misc-next yaml format is from now on
preferred for panel bindings, or at least this is my take on it.
So a yaml conversion would be appreciated, but not mandatory.
>
> diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
> index 169b32e4ee4e..629f38a1d0cd 100644
> --- a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
> +++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
> @@ -1,27 +1,72 @@
> Ilitek ILI9341 display panels
>
> -This binding is for display panels using an Ilitek ILI9341 controller in SPI
> -mode.
> +This binding is for display panels using an Ilitek ILI9341 controller.
> +The display panels are supported in the following graphical input modes:
> +- SPI input mode
> + MIPI-DBI Type 3 Option 1 or Option 3 is used to transfer
> + commands and graphical data
> +- parallel RGB input mode
> + MIPI-DBI Type 3 Option 1 or Option 3 is used for commands
> + MIPI-DPI 18-bit parallel RGB connection is used to transfer
> + graphical data
>
> -Required properties:
> -- compatible: "adafruit,yx240qv29", "ilitek,ili9341"
> -- dc-gpios: D/C pin
> -- reset-gpios: Reset pin
> +
> +SPI input mode:
>
> The node for this driver must be a child node of a SPI controller, hence
> -all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +all mandatory properties described in spi/spi-bus.txt must be specified.
> +
> +Required properties in SPI input mode:
> +- compatible: "adafruit,yx240qv29", "ilitek,ili9341"
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Optional properties in SPI input mode:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- dc-gpios: GPIO spec for the D/C pin, see gpio/gpio.txt
> +- reset-gpios: GPIO spec for the reset pin, see gpio/gpio.txt
> +
> +
> +Parallel RGB input mode:
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in spi/spi-bus.txt must be specified.
> +
> +Required properties in parallel RGB input mode:
> +- compatible: "displaytech,dt024ctft", "ilitek,ili9341"
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Optional properties in parallel RGB input mode:
> +- dc-gpios: GPIO spec for the D/C pin, see gpio/gpio.txt
> +- reset-gpios: GPIO spec for the reset pin, see gpio/gpio.txt
>
> -Optional properties:
> -- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> -- backlight: phandle of the backlight device attached to the panel
> +In parallel RGB input mode,
> +the device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in
> +media/video-interfaces.txt. This node should describe panel's video bus.
>
> -Example:
> +
> +Example in SPI input mode:
> display@0{
> compatible = "adafruit,yx240qv29", "ilitek,ili9341";
> reg = <0>;
> spi-max-frequency = <32000000>;
> dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight>;
> rotation = <270>;
> + };
> +
> +Example in parallel RGB input mode:
> + panel@{
I think you need a number after "@" here.
With this fixed:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH V4 2/5] clocksource/drivers/sysctr: Add clock-frequency property
From: Rob Herring @ 2019-07-10 13:23 UTC (permalink / raw)
To: Anson Huang
Cc: Daniel Lezcano, Thomas Gleixner, Mark Rutland, Shawn Guo,
Sascha Hauer, Sascha Hauer, Fabio Estevam, Leonard Crestez,
Viresh Kumar, Daniel Baluta, Jacky Bai, Lucas Stach, Abel Vesa,
Andrey Smirnov, Carlo Caione, Angus Ainslie (Purism),
Guido Günther, linux-kernel@vger.kernel.org
In-Reply-To: <DB3PR0402MB39167FC68991F071E9E58D81F5F00@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On Tue, Jul 9, 2019 at 7:30 PM Anson Huang <anson.huang@nxp.com> wrote:
>
> Hi, Rob
>
> > On Mon, Jul 1, 2019 at 3:47 AM <Anson.Huang@nxp.com> wrote:
> > >
> > > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > 'dt-bindings: timer: ...' for the subject.
>
> OK, I made a mistake.
>
> >
> > >
> > > Systems which use platform driver model for clock driver require the
> > > clock frequency to be supplied via device tree when system counter
> > > driver is enabled.
> >
> > This is a DT binding. What's a platform driver?
>
> It is just trying to explain why we need to introduce this "clock-frequency"
> property, nothing about the binding and platform driver.
>
> >
> > >
> > > This is necessary as in the platform driver model the of_clk
> > > operations do not work correctly because system counter driver is
> > > initialized in early phase of system boot up, and clock driver using
> > > platform driver model is NOT ready at that time, it will cause system
> > > counter driver initialization failed.
> > >
> > > Add clock-frequency property to the device tree bindings of the NXP
> > > system counter, so the driver can tell timer-of driver to get clock
> > > frequency from DT directly instead of doing of_clk operations via clk
> > > APIs.
> >
> > While you've now given a good explanation why you need this, it all sounds
> > like linux specific issues and a DT change should not be necessary.
> >
> > Presumably, 'clocks' points to a fixed-clock node, right? Just parse the 'clocks'
> > phandle and fetch the frequency from that node if you need to get the
> > frequency 'early'.
>
> Sound like a better solution, I will try that, since the system counter's clock is
> from osc_24m and divided by 3, since different platforms may have different divider,
> so maybe I can create a fixed-clock node in DT, then system counter driver can parse
> the clock and fetch the frequency from that node, will redo a V5 patch.
The divide by 3 can be implied by the compatible. If you need a
different divider, add another compatible.
> >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > No change.
> > > ---
> > > .../devicetree/bindings/timer/nxp,sysctr-timer.txt | 15 +++++++++------
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
> > > b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
> > > index d576599..7088a0e 100644
> > > --- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
> > > +++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
> > > @@ -11,15 +11,18 @@ Required properties:
> > > - reg : Specifies the base physical address and size of the comapre
> > > frame and the counter control, read & compare.
> > > - interrupts : should be the first compare frames' interrupt
> > > -- clocks : Specifies the counter clock.
> > > -- clock-names: Specifies the clock's name of this module
> > > +- clocks : Specifies the counter clock, mutually exclusive with clock-
> > frequency.
> > > +- clock-names : Specifies the clock's name of this module, mutually
> > exclusive with
> > > + clock-frequency.
> > > +- clock-frequency : Specifies system counter clock frequency, mutually
> > exclusive with
> > > + clocks/clock-names.
> >
> > It doesn't really work to say one or the other is needed unless you make the
> > OS support both cases.
>
> The OS already support both cases now with this patch series.
What about FreeBSD or any other OS?
Rob
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
From: Maxime Ripard @ 2019-07-10 11:40 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
In-Reply-To: <CA+E=qVdz4vfU3rtTTKjYdM+4UA+=FWheJfWOMaDtFMnWQ1rHbw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4619 bytes --]
On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > > which should follow edp abstract connector rules? This will be at least
> > > > > consistent with below presentation[1] - eDP requirements depends on
> > > > > integrator. Then if olimex has standard way of dealing with panels
> > > > > present in olimex/teres platforms the driver would then create
> > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > > familiarized with details of these platforms.
> > > >
> > > > That makes sense yes
> > >
> > > Actually, it makes no sense at all. Current implementation for anx6345
> > > driver works fine as is with any panel specified assuming panel delays
> > > are long enough for connected panel. It just doesn't use panel timings
> > > from the driver. Creating a platform driver for connector itself looks
> > > redundant since it can't be reused, it doesn't describe actual
> > > hardware and it's just defeats purpose of DT by introducing
> > > board-specific code.
> >
> > I'm not sure where you got the idea that the purpose of DT is to not
> > have any board-specific code.
>
> I believe DT was an attempt to move to declarative approach for
> describing hardware. Yes, we have different compatibles for different
> devices but they're specific to particular device rather than
> particular board. Device interconnection is described in DT along with
> some properties rather than in board-specific C-file.
You're right, but it's not incompatible with having some code to deal
with some board quirk.
> Introducing board-specific compatible for a connector isn't looking
> right to me.
If that board has a board-specific behaviour for it's connector, then
what's the issue?
You can't describe all the quirks in the all boards using purely
properties.
> > It's perfectly fine to have some, that's even why there's a compatible
> > assigned to each and every board.
> >
> > What the DT is about is allowing us to have a generic behaviour that
> > we can detect: we can have a given behaviour for a given board, and a
> > separate one for another one, and this will be evaluated at runtime.
> >
> > This is *exactly* what this is about: we can have a compatible that
> > sets a given, more specific, behaviour (olimex,teres-edp-connector)
> > while saying that this is compatible with the generic behaviour
> > (edp-connector). That way, any OS will know what quirk to apply if
> > needed, and if not that it can use the generic behaviour.
> >
> > And we could create a generic driver, for the generic behaviour if
> > needed.
> >
> > > There's another issue: if we introduce edp-connector we'll have to
> > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > edp-connector doesn't really solve the issue of multiple panels with
> > > same motherboard.
> >
> > And that's what that compatible is about :)
>
> Sorry, I fail to see how it would be different from using existing
> panels infrastructure and different panels compatibles. I think Rob's
> idea was to introduce generic edp-connector.
Again, there's no such thing as a generic edp-connector. The spec
doesn't define anything related to the power sequence for example.
> If we can't make it generic then let's use panel infrastructure.
Which uses a device specific compatible. Really, I'm not sure what
your objection and / or argument is here.
In addition, when that was brought up in the discussion, you rejected
it because it was inconvenient:
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
And I agree with you on that one.
> > > I'd say DT overlays should be preferred solution here, not another
> > > connector binding.
> >
> > Overlays are a way to apply a device tree dynamically. It's orthogonal
> > to the binding.
>
> It isn't orthogonal to original problem though.
It is. The original problem is that you want to power up whatever is
on the other side of a eDP link using an arbitrary regulator.
This is a "how do I describe that in my DT" problem, and it really has
nothing to do with how the DT is being passed to the kernel.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/11] Arasan SDHCI enhancements and ZynqMP Tap Delays Handling
From: Adrian Hunter @ 2019-07-10 11:33 UTC (permalink / raw)
To: Manish Narani, ulf.hansson, robh+dt, mark.rutland, heiko,
michal.simek, christoph.muellner, philipp.tomsich, viresh.kumar,
scott.branden, ayaka, kernel, tony.xie, rajan.vaja, jolly.shah,
nava.manne, mdf, olof
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <1561958991-21935-1-git-send-email-manish.narani@xilinx.com>
On 1/07/19 8:29 AM, Manish Narani wrote:
> This patch series does the following:
> - Reorganize the Clock Handling in Arasan SD driver
> - Adds new sampling clock in Arasan SD driver
> - Adds support to set Clock Delays in SD Arasan Driver
> - Add SDIO Tap Delay handling in ZynqMP firmware driver
> - Add support for ZynqMP Tap Delays setting in Arasan SD driver
>
> Changes in v2:
> - Replaced the deprecated calls to clock framework APIs
> - Added support for dev_clk_get() call to work for SD card clock
> - Separated the clock data struct
> - Fragmented the patch series in smaller patches to make it more
> readable
>
> This patch series contains a DT patch, which I think should be there to
> maintain the order of commits.
>
> Manish Narani (11):
> dt-bindings: mmc: arasan: Update documentation for SD Card Clock
> arm64: dts: rockchip: Add optional clock property indicating sdcard
> clock
> mmc: sdhci-of-arasan: Replace deprecated clk API calls
> mmc: sdhci-of-arasan: Separate out clk related data to another
> structure
> dt-bindings: mmc: arasan: Update Documentation for the input clock
> mmc: sdhci-of-arasan: Add sampling clock for a phy to use
> dt-bindings: mmc: arasan: Add optional properties for Arasan SDHCI
> mmc: sdhci-of-arasan: Add support to set clock phase delays for SD
> firmware: xilinx: Add SDIO Tap Delay APIs
> dt-bindings: mmc: arasan: Document 'xlnx,zynqmp-8.9a' controller
> mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
>
> .../devicetree/bindings/mmc/arasan,sdhci.txt | 49 ++-
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 +-
> drivers/firmware/xilinx/zynqmp.c | 48 +++
> drivers/mmc/host/sdhci-of-arasan.c | 453 ++++++++++++++++++++-
> include/linux/firmware/xlnx-zynqmp.h | 15 +-
> 5 files changed, 540 insertions(+), 29 deletions(-)
>
For SDHCI:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
^ permalink raw reply
* [PATCH 1/1] arm64: dts: sdm845: Add device node for Last level cache controller
From: Vivek Gautam @ 2019-07-10 11:29 UTC (permalink / raw)
To: agross, robh+dt, bjorn.andersson
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel,
Sai Prakash Ranjan, Vivek Gautam
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Last level cache (aka. system cache) controller provides control
over the last level cache present on SDM845. This cache lies after
the memory noc, right before the DDR.
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 4babff5f19b5..314241a99290 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1275,6 +1275,13 @@
};
};
+ cache-controller@1100000 {
+ compatible = "qcom,sdm845-llcc";
+ reg = <0 0x1100000 0 0x200000>, <0 0x1300000 0 0x50000>;
+ reg-names = "llcc_base", "llcc_broadcast_base";
+ interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sdm845-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH V13 05/12] PCI: dwc: Add ext config space capability search API
From: Vidya Sagar @ 2019-07-10 11:27 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, robh+dt, mark.rutland, thierry.reding, jonathanh,
kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <20190710103709.GA4063@e121166-lin.cambridge.arm.com>
On 7/10/2019 4:07 PM, Lorenzo Pieralisi wrote:
> On Wed, Jul 10, 2019 at 11:52:05AM +0530, Vidya Sagar wrote:
>> Add extended configuration space capability search API using struct dw_pcie *
>> pointer
>
> Sentences are terminated with a period and this is v13 not v1, which
> proves that you do not read the commit logs you write.
>
> I need you guys to understand that I can't rewrite commit logs all
> the time, I do not want to go as far as not accepting your patches
> anymore so please do pay attention to commit log details they
> are as important as the code itself.
>
> https://lore.kernel.org/linux-pci/20171026223701.GA25649@bhelgaas-glaptop.roam.corp.google.com/
My sincere apologies.
Since I didn't touch this patch much all through this series, I missed it.
I'll make a point to not make such mistakes again.
Do you want me to send a new version fixing it?
Thanks,
Vidya Sagar
>
> Thanks,
> Lorenzo
>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
>> Acked-by: Thierry Reding <treding@nvidia.com>
>> ---
>> V13:
>> * None
>>
>> V12:
>> * None
>>
>> V11:
>> * None
>>
>> V10:
>> * None
>>
>> V9:
>> * Added Acked-by from Thierry
>>
>> V8:
>> * Changed data types of return and arguments to be inline with data being returned
>> and passed.
>>
>> V7:
>> * None
>>
>> V6:
>> * None
>>
>> V5:
>> * None
>>
>> V4:
>> * None
>>
>> V3:
>> * None
>>
>> V2:
>> * This is a new patch in v2 series
>>
>> drivers/pci/controller/dwc/pcie-designware.c | 41 ++++++++++++++++++++
>> drivers/pci/controller/dwc/pcie-designware.h | 1 +
>> 2 files changed, 42 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
>> index 7818b4febb08..181449e342f1 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware.c
>> @@ -53,6 +53,47 @@ u8 dw_pcie_find_capability(struct dw_pcie *pci, u8 cap)
>> }
>> EXPORT_SYMBOL_GPL(dw_pcie_find_capability);
>>
>> +static u16 dw_pcie_find_next_ext_capability(struct dw_pcie *pci, u16 start,
>> + u8 cap)
>> +{
>> + u32 header;
>> + int ttl;
>> + int pos = PCI_CFG_SPACE_SIZE;
>> +
>> + /* minimum 8 bytes per capability */
>> + ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
>> +
>> + if (start)
>> + pos = start;
>> +
>> + header = dw_pcie_readl_dbi(pci, pos);
>> + /*
>> + * If we have no capabilities, this is indicated by cap ID,
>> + * cap version and next pointer all being 0.
>> + */
>> + if (header == 0)
>> + return 0;
>> +
>> + while (ttl-- > 0) {
>> + if (PCI_EXT_CAP_ID(header) == cap && pos != start)
>> + return pos;
>> +
>> + pos = PCI_EXT_CAP_NEXT(header);
>> + if (pos < PCI_CFG_SPACE_SIZE)
>> + break;
>> +
>> + header = dw_pcie_readl_dbi(pci, pos);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +u16 dw_pcie_find_ext_capability(struct dw_pcie *pci, u8 cap)
>> +{
>> + return dw_pcie_find_next_ext_capability(pci, 0, cap);
>> +}
>> +EXPORT_SYMBOL_GPL(dw_pcie_find_ext_capability);
>> +
>> int dw_pcie_read(void __iomem *addr, int size, u32 *val)
>> {
>> if (!IS_ALIGNED((uintptr_t)addr, size)) {
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
>> index d8c66a6827dc..11c223471416 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -252,6 +252,7 @@ struct dw_pcie {
>> container_of((endpoint), struct dw_pcie, ep)
>>
>> u8 dw_pcie_find_capability(struct dw_pcie *pci, u8 cap);
>> +u16 dw_pcie_find_ext_capability(struct dw_pcie *pci, u8 cap);
>>
>> int dw_pcie_read(void __iomem *addr, int size, u32 *val);
>> int dw_pcie_write(void __iomem *addr, int size, u32 val);
>> --
>> 2.17.1
>>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8mq: correct usb controller clocks
From: jun.li @ 2019-07-10 11:19 UTC (permalink / raw)
To: shawnguo, sboyd, robh+dt
Cc: mark.rutland, peter.chen, agx, ping.bai, Anson.Huang, ccaione,
andrew.smirnov, mturquette, angus, linux-clk, abel.vesa,
devicetree, linux-imx, kernel, l.stach, festevam, s.hauer,
linux-arm-kernel, jun.li
In-Reply-To: <20190710111917.6615-1-jun.li@nxp.com>
From: Li Jun <jun.li@nxp.com>
The correct clock for "bus_early", "ref", "suspend" should be:
IMX8MQ_CLK_USB1_CTRL_ROOT, IMX8MQ_CLK_USB_CORE_REF, IMX8MQ_CLK_32K,
especially we may need the right suspend clock rate to set register
in controller driver.
Signed-off-by: Li Jun <jun.li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index d09b808..a43ddac 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -901,9 +901,9 @@
usb_dwc3_0: usb@38100000 {
compatible = "fsl,imx8mq-dwc3", "snps,dwc3";
reg = <0x38100000 0x10000>;
- clocks = <&clk IMX8MQ_CLK_USB_BUS>,
+ clocks = <&clk IMX8MQ_CLK_USB1_CTRL_ROOT>,
<&clk IMX8MQ_CLK_USB_CORE_REF>,
- <&clk IMX8MQ_CLK_USB1_CTRL_ROOT>;
+ <&clk IMX8MQ_CLK_32K>;
clock-names = "bus_early", "ref", "suspend";
assigned-clocks = <&clk IMX8MQ_CLK_USB_BUS>,
<&clk IMX8MQ_CLK_USB_CORE_REF>;
@@ -933,9 +933,9 @@
usb_dwc3_1: usb@38200000 {
compatible = "fsl,imx8mq-dwc3", "snps,dwc3";
reg = <0x38200000 0x10000>;
- clocks = <&clk IMX8MQ_CLK_USB_BUS>,
+ clocks = <&clk IMX8MQ_CLK_USB2_CTRL_ROOT>,
<&clk IMX8MQ_CLK_USB_CORE_REF>,
- <&clk IMX8MQ_CLK_USB2_CTRL_ROOT>;
+ <&clk IMX8MQ_CLK_32K>;
clock-names = "bus_early", "ref", "suspend";
assigned-clocks = <&clk IMX8MQ_CLK_USB_BUS>,
<&clk IMX8MQ_CLK_USB_CORE_REF>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] clk: imx8mq: set correct parent for usb ctrl clocks
From: jun.li @ 2019-07-10 11:19 UTC (permalink / raw)
To: shawnguo, sboyd, robh+dt
Cc: mark.rutland, peter.chen, agx, ping.bai, Anson.Huang, ccaione,
andrew.smirnov, mturquette, angus, linux-clk, abel.vesa,
devicetree, linux-imx, kernel, l.stach, festevam, s.hauer,
linux-arm-kernel, jun.li
From: Li Jun <jun.li@nxp.com>
Per latest imx8mq datasheet of CCM, the parent of usb1_ctrl_root_clk
and usb2_ctrl_root_clk is usb_bus.
Signed-off-by: Li Jun <jun.li@nxp.com>
---
drivers/clk/imx/clk-imx8mq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index d407a07..c7d1546 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -523,8 +523,8 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_CLK_UART2_ROOT] = imx_clk_gate4("uart2_root_clk", "uart2", base + 0x44a0, 0);
clks[IMX8MQ_CLK_UART3_ROOT] = imx_clk_gate4("uart3_root_clk", "uart3", base + 0x44b0, 0);
clks[IMX8MQ_CLK_UART4_ROOT] = imx_clk_gate4("uart4_root_clk", "uart4", base + 0x44c0, 0);
- clks[IMX8MQ_CLK_USB1_CTRL_ROOT] = imx_clk_gate4("usb1_ctrl_root_clk", "usb_core_ref", base + 0x44d0, 0);
- clks[IMX8MQ_CLK_USB2_CTRL_ROOT] = imx_clk_gate4("usb2_ctrl_root_clk", "usb_core_ref", base + 0x44e0, 0);
+ clks[IMX8MQ_CLK_USB1_CTRL_ROOT] = imx_clk_gate4("usb1_ctrl_root_clk", "usb_bus", base + 0x44d0, 0);
+ clks[IMX8MQ_CLK_USB2_CTRL_ROOT] = imx_clk_gate4("usb2_ctrl_root_clk", "usb_bus", base + 0x44e0, 0);
clks[IMX8MQ_CLK_USB1_PHY_ROOT] = imx_clk_gate4("usb1_phy_root_clk", "usb_phy_ref", base + 0x44f0, 0);
clks[IMX8MQ_CLK_USB2_PHY_ROOT] = imx_clk_gate4("usb2_phy_root_clk", "usb_phy_ref", base + 0x4500, 0);
clks[IMX8MQ_CLK_USDHC1_ROOT] = imx_clk_gate4("usdhc1_root_clk", "usdhc1", base + 0x4510, 0);
--
2.7.4
^ permalink raw reply related
* RE: [PATCHv6 00/28] PCI: mobiveil: fixes for Mobiveil PCIe Host Bridge IP driver
From: Z.q. Hou @ 2019-07-10 10:59 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
bhelgaas@google.com, robh+dt@kernel.org, mark.rutland@arm.com,
l.subrahmanya@mobiveil.co.in, shawnguo@kernel.org, Leo Li,
catalin.marinas@arm.com, will.deacon@arm.com, Mingkai Hu,
M.h. Lian, Xiaowei Bao
In-Reply-To: <20190708113503.GA21942@e121166-lin.cambridge.arm.com>
Hi Lorenzo,
Thanks for your comments!
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年7月8日 19:35
> To: Z.q. Hou <zhiqiang.hou@nxp.com>
> Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> l.subrahmanya@mobiveil.co.in; shawnguo@kernel.org; Leo Li
> <leoyang.li@nxp.com>; catalin.marinas@arm.com; will.deacon@arm.com;
> Mingkai Hu <mingkai.hu@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>;
> Xiaowei Bao <xiaowei.bao@nxp.com>
> Subject: Re: [PATCHv6 00/28] PCI: mobiveil: fixes for Mobiveil PCIe Host
> Bridge IP driver
>
> On Fri, Jul 05, 2019 at 05:56:28PM +0800, Hou Zhiqiang wrote:
> > This patch set is to add fixes for Mobiveil PCIe Host driver.
> > Splited #2, #3, #9 and #10 of v5 patches.
> >
> > Hou Zhiqiang (28):
> > PCI: mobiveil: Unify register accessors
> > PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
> > PCI: mobiveil: Fix PCI base address in MEM/IO outbound windows
> > PCI: mobiveil: Update the resource list traversal function
> > PCI: mobiveil: Use WIN_NUM_0 explicitly for CFG outbound window
> > PCI: mobiveil: Use the 1st inbound window for MEM inbound
> > transactions
> > PCI: mobiveil: Fix the Class Code field
> > PCI: mobiveil: Move the link up waiting out of mobiveil_host_init()
> > PCI: mobiveil: Move IRQ chained handler setup out of DT parse
> > PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers
> > PCI: mobiveil: Fix devfn check in mobiveil_pcie_valid_device()
> > dt-bindings: PCI: mobiveil: Change gpio_slave and apb_csr to optional
> > PCI: mobiveil: Reformat the code for readability
> > PCI: mobiveil: Make the register updating more readable
> > PCI: mobiveil: Revise the MEM/IO outbound window initialization
> > PCI: mobiveil: Fix the returned error number
> > PCI: mobiveil: Remove an unnecessary return value check
> > PCI: mobiveil: Remove redundant var definitions and register read
> > operations
> > PCI: mobiveil: Fix the valid check for inbound and outbound window
> > PCI: mobiveil: Add the statistic of initialized inbound windows
> > PCI: mobiveil: Clear the target fields before updating the register
> > PCI: mobiveil: Mask out the lower 10-bit hardcode window size
> > PCI: mobiveil: Add upper 32-bit CPU base address setup in outbound
> > window
> > PCI: mobiveil: Add upper 32-bit PCI base address setup in inbound
> > window
> > PCI: mobiveil: Fix the CPU base address setup in inbound window
> > PCI: mobiveil: Move PCIe PIO enablement out of inbound window
> routine
> > PCI: mobiveil: Fix infinite-loop in the INTx process
> > PCI: mobiveil: Fix the potential INTx missing problem
> >
> > .../devicetree/bindings/pci/mobiveil-pcie.txt | 2 +
> > drivers/pci/controller/pcie-mobiveil.c | 529
> ++++++++++++--------
> > 2 files changed, 318 insertions(+), 213 deletions(-)
> >
>
> OK, I rewrote most of commit logs, dropped patch 25 since I do not
> understand the commit log, pushed to pci/mobiveil tentatively for v5.3.
The patch #25 is to fix the wrongly programming of the CPU base address of
the inbound windows. The current code set the CPU base address with the
PCI base address parameter which is the caller passed to set the PCI base
address of the inbound window, and the upper 32-bit of the CPU base address
of the inbound window is not set in current code.
So it means the current code only support 1:1 inbound window setting & the
CPU base address must be < 4GB. It won't work if in future someone change
it to non 1:1 mapping or the CPU base address of the inbound window > 4GB.
So, I will resend it separately.
> Having said that, you should improve commit logs writing it took me too
> much time to check them all and rewrite them.
>
> Never ever again post a massive series like this mixing refactoring fixes and
> clean-ups it was painful to review/rebase, please split patch series into small
> chunks to make my life much easier.
I understand it is wearisome, but I just want to make it better and easier to
add new driver for other developers. I will try to not mix the distinct changes
so that easy to maintain.
Thank you so much for recomposing of these changelogs.
> Please check my pci/mobiveil branch and report back if something is not in
> order.
Yes, and thanks again.
B.R,
Zhiqiang
> Lorenzo
^ permalink raw reply
* Re: [PATCH 1/3] opp: core: add regulators enable and disable
From: Kamil Konieczny @ 2019-07-10 10:43 UTC (permalink / raw)
To: Viresh Kumar
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Chanwoo Choi,
Krzysztof Kozlowski, Kukjin Kim, Kyungmin Park, Mark Rutland,
MyungJoo Ham, Nishanth Menon, Rob Herring, Stephen Boyd,
Viresh Kumar, devicetree, linux-arm-kernel, linux-kernel,
linux-pm, linux-samsung-soc
In-Reply-To: <20190709054014.o3g4e6gbovrq3vvn@vireshk-i7>
On 09.07.2019 07:40, Viresh Kumar wrote:
> On 08-07-19, 16:11, k.konieczny@partner.samsung.com wrote:
>> From: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>
>> Add enable regulators to dev_pm_opp_set_regulators() and disable
>> regulators to dev_pm_opp_put_regulators(). This prepares for
>> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
>>
>> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
>> ---
>> drivers/opp/core.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>> index 0e7703fe733f..947cac452854 100644
>> --- a/drivers/opp/core.c
>> +++ b/drivers/opp/core.c
>> @@ -1580,8 +1580,19 @@ struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
>> if (ret)
>> goto free_regulators;
>>
>> + for (i = 0; i < opp_table->regulator_count; i++) {
>> + ret = regulator_enable(opp_table->regulators[i]);
>> + if (ret < 0)
>> + goto disable;
>> + }
>
> I am wondering on why is this really required as this isn't done for
> any other platform, probably because the regulators are enabled by
> bootloader and are always on.
It is not ABI break, it should work with existing DTBs
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH 1/3] opp: core: add regulators enable and disable
From: Kamil Konieczny @ 2019-07-10 10:42 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, Rob Herring,
linux-arm-kernel, Bartlomiej Zolnierkiewicz, Stephen Boyd,
Viresh Kumar, linux-pm, linux-kernel, Krzysztof Kozlowski,
Chanwoo Choi, Kyungmin Park, Kukjin Kim, MyungJoo Ham, devicetree,
Marek Szyprowski
In-Reply-To: <3d6eacb8-ed8d-d4ac-1c36-6224ab88a5dc@partner.samsung.com>
On 10.07.2019 12:16, Kamil Konieczny wrote:
>
>
> On 09.07.2019 07:40, Viresh Kumar wrote:
>> On 08-07-19, 16:11, k.konieczny@partner.samsung.com wrote:
>>> From: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>>
>>> Add enable regulators to dev_pm_opp_set_regulators() and disable
>>> regulators to dev_pm_opp_put_regulators(). This prepares for
>>> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
>>>
>>> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
>>> ---
>>> drivers/opp/core.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>>> index 0e7703fe733f..947cac452854 100644
>>> --- a/drivers/opp/core.c
>>> +++ b/drivers/opp/core.c
>>> @@ -1580,8 +1580,19 @@ struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
>>> if (ret)
>>> goto free_regulators;
>>>
>>> + for (i = 0; i < opp_table->regulator_count; i++) {
>>> + ret = regulator_enable(opp_table->regulators[i]);
>>> + if (ret < 0)
>>> + goto disable;
>>> + }
>>
>> I am wondering on why is this really required as this isn't done for
>> any other platform, probably because the regulators are enabled by
>> bootloader and are always on.
>
> It was not enabled for historical reasons, from design point regualtors
> should be enabled before use.
On Exynos platform devfreq driver (exynos-bus) always enabled them,
so I wanted to preserve the current behaviour.
I've also checked the change with cpufreq-dt driver and it doesn't cause
issues.
Do you find this change acceptable?
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
^ 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