Re: [PATCH v2 05/13] mtd: devices: Replace all spi->chip_select and spi->cs_gpiod references with function call
On 1/19/23 19:53, Amit Kumar Mahapatra wrote: Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra --- drivers/mtd/devices/mtd_dataflash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c index 3bbaa590c768..1d3b2a94581f 100644 --- a/drivers/mtd/devices/mtd_dataflash.c +++ b/drivers/mtd/devices/mtd_dataflash.c @@ -639,7 +639,7 @@ static int add_dataflash_otp(struct spi_device *spi, char *name, int nr_pages, /* name must be usable with cmdlinepart */ sprintf(priv->name, "spi%d.%d-%s", - spi->master->bus_num, spi->chip_select, + spi->master->bus_num, spi_get_chipselect(spi, 0), name); device = >mtd; Reviewed-by: Michal Simek Thanks, Michal
Re: [PATCH v2 01/13] spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod
i_set_cs(spi, activate);
- spi->controller->last_cs = enable ? spi->chip_select : -1;
+ spi->controller->last_cs = enable ? spi_get_chipselect(spi, 0) : -1;
spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
- if ((spi->cs_gpiod || !spi->controller->set_cs_timing) && !activate) {
+ if ((spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) &&
!activate)
spi_delay_exec(>cs_hold, NULL);
- }
if (spi->mode & SPI_CS_HIGH)
enable = !enable;
- if (spi->cs_gpiod) {
+ if (spi_get_csgpiod(spi, 0)) {
if (!(spi->mode & SPI_NO_CS)) {
/*
* Historically ACPI has no means of the GPIO polarity
and
@@ -1000,10 +999,10 @@ static void spi_set_cs(struct spi_device *spi, bool
enable, bool force)
* into account.
*/
if (has_acpi_companion(>dev))
- gpiod_set_value_cansleep(spi->cs_gpiod,
!enable);
+ gpiod_set_value_cansleep(spi_get_csgpiod(spi,
0), !enable);
else
/* Polarity handled by GPIO library */
- gpiod_set_value_cansleep(spi->cs_gpiod,
activate);
+ gpiod_set_value_cansleep(spi_get_csgpiod(spi,
0), activate);
}
/* Some SPI masters need both GPIO CS & slave_select */
if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
@@ -1013,7 +1012,7 @@ static void spi_set_cs(struct spi_device *spi, bool
enable, bool force)
spi->controller->set_cs(spi, !enable);
}
- if (spi->cs_gpiod || !spi->controller->set_cs_timing) {
+ if (spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) {
if (activate)
spi_delay_exec(>cs_setup, NULL);
else
@@ -2304,7 +2303,7 @@ static int of_spi_parse_dt(struct spi_controller *ctlr,
struct spi_device *spi,
nc, rc);
return rc;
}
- spi->chip_select = value;
+ spi_set_chipselect(spi, 0, value);
/* Device speed */
if (!of_property_read_u32(nc, "spi-max-frequency", ))
@@ -2423,7 +2422,7 @@ struct spi_device *spi_new_ancillary_device(struct
spi_device *spi,
strscpy(ancillary->modalias, "dummy", sizeof(ancillary->modalias));
/* Use provided chip-select for ancillary device */
- ancillary->chip_select = chip_select;
+ spi_set_chipselect(ancillary, 0, chip_select);
/* Take over SPI mode/speed from SPI main device */
ancillary->max_speed_hz = spi->max_speed_hz;
@@ -2670,7 +2669,7 @@ struct spi_device *acpi_spi_device_alloc(struct
spi_controller *ctlr,
spi->mode|= lookup.mode;
spi->irq = lookup.irq;
spi->bits_per_word = lookup.bits_per_word;
- spi->chip_select = lookup.chip_select;
+ spi_set_chipselect(spi, 0, lookup.chip_select);
return spi;
}
@@ -3632,7 +3631,7 @@ static int spi_set_cs_timing(struct spi_device *spi)
struct device *parent = spi->controller->dev.parent;
int status = 0;
- if (spi->controller->set_cs_timing && !spi->cs_gpiod) {
+ if (spi->controller->set_cs_timing && !spi_get_csgpiod(spi, 0)) {
if (spi->controller->auto_runtime_pm) {
status = pm_runtime_get_sync(parent);
if (status < 0) {
@@ -3837,7 +3836,7 @@ static int __spi_validate(struct spi_device *spi, struct
spi_message *message)
* cs_change is set for each transfer.
*/
if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) ||
- spi->cs_gpiod)) {
+ spi_get_csgpiod(spi, 0))) {
size_t maxsize;
int ret;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 9a32495fbb1f..9b23a1d0dd0d 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -263,6 +263,26 @@ static inline void *spi_get_drvdata(struct spi_device *spi)
return dev_get_drvdata(>dev);
}
+static inline u8 spi_get_chipselect(struct spi_device *spi, u8 idx)
+{
+ return spi->chip_select;
+}
+
+static inline void spi_set_chipselect(struct spi_device *spi, u8 idx, u8
chipselect)
+{
+ spi->chip_select = chipselect;
+}
+
+static inline struct gpio_desc *spi_get_csgpiod(struct spi_device *spi, u8 idx)
+{
+ return spi->cs_gpiod;
+}
+
+static inline void spi_set_csgpiod(struct spi_device *spi, u8 idx, struct
gpio_desc *csgpiod)
+{
+ spi->cs_gpiod = csgpiod;
+}
+
struct spi_message;
/**
Lars suggested this style in v1 version of this patch here.
https://lore.kernel.org/all/12fe1b84-1981-bf56-9323-b7f5b698c...@metafoo.de/
That's why let me also add his
Suggested-by: Lars-Peter Clausen
And
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v2 07/13] platform/x86: serial-multi-instantiate: Replace all spi->chip_select and spi->cs_gpiod references with function call
On 1/19/23 19:53, Amit Kumar Mahapatra wrote: Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra --- drivers/platform/x86/serial-multi-instantiate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/serial-multi-instantiate.c b/drivers/platform/x86/serial-multi-instantiate.c index 5362f1a7b77c..270a4700d25d 100644 --- a/drivers/platform/x86/serial-multi-instantiate.c +++ b/drivers/platform/x86/serial-multi-instantiate.c @@ -139,7 +139,8 @@ static int smi_spi_probe(struct platform_device *pdev, struct smi *smi, goto error; } - dev_dbg(dev, "SPI device %s using chip select %u", name, spi_dev->chip_select); + dev_dbg(dev, "SPI device %s using chip select %u", name, + spi_get_chipselect(spi_dev, 0)); smi->spi_devs[i] = spi_dev; smi->spi_num++; Reviewed-by: Michal Simek Thanks, Michal
Re: [PATCH v2 02/13] spi: Replace all spi->chip_select and spi->cs_gpiod references with function call
/spi-xcomm.c | 2 +- drivers/spi/spi-xilinx.c | 6 +++--- drivers/spi/spi-xlp.c | 4 ++-- drivers/spi/spi-zynq-qspi.c | 2 +- drivers/spi/spi-zynqmp-gqspi.c| 2 +- drivers/spi/spidev.c | 6 +++--- include/trace/events/spi.h| 10 +- 92 files changed, 315 insertions(+), 310 deletions(-) Reviewed-by: Michal Simek Thanks, Michal
Re: [PATCH v2 10/13] mtd: spi-nor: Add stacked memories support in spi-nor
On 1/19/23 19:53, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate
parameter structure. So, the flash parameter member(*params) of the spi_nor
structure is changed to an array (*params[2]). The array is used to store
the parameters of each flash connected in stacked configuration.
The current implementation assumes that a maximum of two flashes are
connected in stacked mode and both the flashes are of same make but can
differ in sizes. So, except the sizes all other flash parameters of both
the flashes are identical.
SPI-NOR is not aware of the chip_select values, for any incoming request
SPI-NOR will decide the flash index with the help of individual flash size
and the configuration type (single/stacked). SPI-NOR will pass on the flash
index information to the SPI core & SPI driver by setting the appropriate
bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of
nor->spimem->spi->cs_index_mask is set then the driver would
assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra
---
drivers/mtd/spi-nor/core.c | 282 +---
drivers/mtd/spi-nor/core.h | 4 +
drivers/mtd/spi-nor/otp.c | 4 +-
include/linux/mtd/spi-nor.h | 12 +-
4 files changed, 246 insertions(+), 56 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 8a4a54bf2d0e..bb7326dc8b70 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1441,13 +1441,18 @@ static int spi_nor_erase_multi_sectors(struct spi_nor
*nor, u64 addr, u32 len)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 addr, len;
+ struct spi_nor_flash_parameter *params;
+ u32 addr, len, offset, cur_cs_num = 0;
uint32_t rem;
int ret;
+ u64 sz;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
(long long)instr->len);
+ params = spi_nor_get_params(nor, 0);
+ sz = params->size;
+
if (spi_nor_has_uniform_erase(nor)) {
div_u64_rem(instr->len, mtd->erasesize, );
if (rem)
@@ -1465,26 +1470,30 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
if (len == mtd->size && !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
unsigned long timeout;
- ret = spi_nor_write_enable(nor);
- if (ret)
- goto erase_err;
+ while (cur_cs_num < SNOR_FLASH_CNT_MAX && params) {
+ nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num;
+ ret = spi_nor_write_enable(nor);
+ if (ret)
+ goto erase_err;
- ret = spi_nor_erase_chip(nor);
- if (ret)
- goto erase_err;
+ ret = spi_nor_erase_chip(nor);
+ if (ret)
+ goto erase_err;
- /*
-* Scale the timeout linearly with the size of the flash, with
-* a minimum calibrated to an old 2MB flash. We could try to
-* pull these from CFI/SFDP, but these values should be good
-* enough for now.
-*/
- timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
- CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
- (unsigned long)(mtd->size / SZ_2M));
- ret = spi_nor_wait_till_ready_with_timeout(nor, timeout);
- if (ret)
- goto erase_err;
+ /*
+* Scale the timeout linearly with the size of the
flash, with
+* a minimum calibrated to an old 2MB flash. We could
try to
+* pull these from CFI/SFDP, but these values should be
good
+* enough for now.
+*/
+ timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
+ CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
+ (unsigned long)(params->size / SZ_2M));
+ ret = spi_nor_wait_till_ready_with_timeout(nor,
timeout);
+ if (ret)
+ goto erase_err;
+ cur_cs_num++;
+ }
/* REVISIT in some cases we could speed up erasing large regions
* by using SPINOR_OP_SE instead of SPINOR_OP_BE_4K. We may have set up
@@ -1493,12 +1502,26 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
/* "sector"-at-a-time erase */
} else if (spi_nor_has_uniform_erase(nor)) {
+ /* Determine the flash from which the operation need to start */
+ while ((cur_cs_num < SNOR_FLASH_CNT_MAX) && (addr
Re: [PATCH v2 06/13] staging: Replace all spi->chip_select and spi->cs_gpiod references with function call
On 1/19/23 19:53, Amit Kumar Mahapatra wrote: Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra --- drivers/staging/fbtft/fbtft-core.c | 2 +- drivers/staging/greybus/spilib.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index afaba94d1d1c..3a4abf3bae40 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -840,7 +840,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info) sprintf(text1, ", %zu KiB buffer memory", par->txbuf.len >> 10); if (spi) sprintf(text2, ", spi%d.%d at %d MHz", spi->master->bus_num, - spi->chip_select, spi->max_speed_hz / 100); + spi_get_chipselect(spi, 0), spi->max_speed_hz / 100); dev_info(fb_info->dev, "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n", fb_info->fix.id, fb_info->var.xres, fb_info->var.yres, diff --git a/drivers/staging/greybus/spilib.c b/drivers/staging/greybus/spilib.c index ad0700a0bb81..efb3bec58e15 100644 --- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -237,7 +237,7 @@ static struct gb_operation *gb_spi_operation_create(struct gb_spilib *spi, request = operation->request->payload; request->count = cpu_to_le16(count); request->mode = dev->mode; - request->chip_select = dev->chip_select; + request->chip_select = spi_get_chipselect(dev, 0); gb_xfer = >transfers[0]; tx_data = gb_xfer + count; /* place tx data after last gb_xfer */ Reviewed-by: Michal Simek Thanks, Michal
Re: [PATCH v2 04/13] iio: imu: Replace all spi->chip_select and spi->cs_gpiod references with function call
On 1/19/23 19:53, Amit Kumar Mahapatra wrote:
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and
spi->cs_gpiod references with get or set API calls.
While adding multi-cs support in further patches the chip_select & cs_gpiod
members of the spi_device structure would be converted to arrays & the
"idx" parameter of the APIs would be used as array index i.e.,
spi->chip_select[idx] & spi->cs_gpiod[idx] respectively.
Signed-off-by: Amit Kumar Mahapatra
---
drivers/iio/imu/adis16400.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/imu/adis16400.c b/drivers/iio/imu/adis16400.c
index c02fc35dceb4..3eda32e12a53 100644
--- a/drivers/iio/imu/adis16400.c
+++ b/drivers/iio/imu/adis16400.c
@@ -466,7 +466,7 @@ static int adis16400_initial_setup(struct iio_dev
*indio_dev)
dev_info(_dev->dev, "%s: prod_id 0x%04x at CS%d (irq %d)\n",
indio_dev->name, prod_id,
- st->adis.spi->chip_select, st->adis.spi->irq);
+ spi_get_chipselect(st->adis.spi, 0), st->adis.spi->irq);
}
/* use high spi speed if possible */
if (st->variant->flags & ADIS16400_HAS_SLOW_MODE) {
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v2 03/13] net: Replace all spi->chip_select and spi->cs_gpiod references with function call
tatic int slic_ds26522_probe(struct spi_device *spi)
ret = slic_ds26522_init_configure(spi);
if (ret == 0)
- pr_info("DS26522 cs%d configured\n", spi->chip_select);
+ pr_info("DS26522 cs%d configured\n", spi_get_chipselect(spi,
0));
return ret;
}
diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c
b/drivers/net/wireless/marvell/libertas/if_spi.c
index ff1c7ec8c450..1225fc0e3352 100644
--- a/drivers/net/wireless/marvell/libertas/if_spi.c
+++ b/drivers/net/wireless/marvell/libertas/if_spi.c
@@ -1051,7 +1051,7 @@ static int if_spi_init_card(struct if_spi_card *card)
"spi->max_speed_hz=%d\n",
card->card_id, card->card_rev,
card->spi->master->bus_num,
- card->spi->chip_select,
+ spi_get_chipselect(card->spi, 0),
card->spi->max_speed_hz);
err = if_spi_prog_helper_firmware(card, helper);
if (err)
diff --git a/drivers/net/wireless/silabs/wfx/bus_spi.c
b/drivers/net/wireless/silabs/wfx/bus_spi.c
index 7fb1afb8ed31..160b90114aad 100644
--- a/drivers/net/wireless/silabs/wfx/bus_spi.c
+++ b/drivers/net/wireless/silabs/wfx/bus_spi.c
@@ -208,7 +208,7 @@ static int wfx_spi_probe(struct spi_device *func)
/* Trace below is also displayed by spi_setup() if compiled with DEBUG */
dev_dbg(>dev, "SPI params: CS=%d, mode=%d bits/word=%d
speed=%d\n",
- func->chip_select, func->mode, func->bits_per_word,
func->max_speed_hz);
+ spi_get_chipselect(func, 0), func->mode, func->bits_per_word,
func->max_speed_hz);
if (func->bits_per_word != 16 && func->bits_per_word != 8)
dev_warn(>dev, "unusual bits/word value: %d\n",
func->bits_per_word);
if (func->max_speed_hz > 5000)
diff --git a/drivers/net/wireless/st/cw1200/cw1200_spi.c
b/drivers/net/wireless/st/cw1200/cw1200_spi.c
index fe0d220da44d..c82c0688b549 100644
--- a/drivers/net/wireless/st/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/st/cw1200/cw1200_spi.c
@@ -378,7 +378,7 @@ static int cw1200_spi_probe(struct spi_device *func)
func->mode = SPI_MODE_0;
pr_info("cw1200_wlan_spi: Probe called (CS %d M %d BPW %d CLK %d)\n",
- func->chip_select, func->mode, func->bits_per_word,
+ spi_get_chipselect(func, 0), func->mode, func->bits_per_word,
func->max_speed_hz);
if (cw1200_spi_on(plat_data)) {
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v2 36/37] arm64: dts: zynqmp: Add ports for the DisplayPort subsystem
Hi Laurent, On 10/19/22 17:59, Laurent Pinchart wrote: Hi Michal, I plan to send a pull request for the series soon. Patches 01/37 to 35/37 will go through the DRM tree. How would you like to handle this patch and the next ? They depend on the DT binding changes in 01/37. No problem for me if you want to take them via DRM tree (which is the easiest way for me). In that case feel free to add my Acked-by: Michal Simek to both of that patches. If you want me to queue it via my tree I will cherry pick that two patches. Thanks, Michal
[PATCH] dt-bindings: display: xilinx: Fix example with psgtr
Commit cea0f76a483d ("dt-bindings: phy: Add DT bindings for Xilinx ZynqMP
PSGTR PHY") clearly defines #phy-cells as 4. In past 5 cells were used by
it never went to upstream. That's why fix example by using only 4 cells
instead of 5.
Fixes: e7c7970a678d ("dt-bindings: display: xlnx: Add ZynqMP DP subsystem
bindings")
Signed-off-by: Michal Simek
---
.../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
index d88bd93f4b80..10ec78ca1c65 100644
--- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
@@ -160,8 +160,8 @@ examples:
<_dpdma 2>,
<_dpdma 3>;
-phys = < 1 PHY_TYPE_DP 0 3 2700>,
- < 0 PHY_TYPE_DP 1 3 2700>;
+phys = < 1 PHY_TYPE_DP 0 3>,
+ < 0 PHY_TYPE_DP 1 3>;
phy-names = "dp-phy0", "dp-phy1";
};
--
2.33.1
Re: [V2][PATCH] drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers
Hi, st 24. 3. 2021 v 4:15 odesílatel Laurent Pinchart napsal: > > Hi Quanyang, > > Thank you for the patch. > > On Tue, Mar 23, 2021 at 10:55:01AM +0800, quanyang.w...@windriver.com wrote: > > From: Quanyang Wang > > > > When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the > > error log as below: > > > > root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko > > [ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for > > fd4a.display on minor 0 > > [ 88.529906] Console: switching to colour frame buffer device 128x48 > > [ 88.549402] zynqmp-dpsub fd4a.display: [drm] fb0: zynqmp-dpsubdrm > > frame buffer device > > [ 88.571624] zynqmp-dpsub fd4a.display: ZynqMP DisplayPort Subsystem > > driver probed > > root@xilinx-zynqmp:~# rmmod zynqmp_dpsub > > [ 94.023404] Console: switching to colour dummy device 80x25 > > root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko > > > > > > This is because that in zynqmp_dp_probe it tries to access some DP > > registers while the DP controller is still in the reset state. When > > running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in > > zynqmp_dp_phy_exit is called to force the DP controller into the reset > > state. Then insmod will call zynqmp_dp_probe to program the DP registers, > > but at this moment the DP controller hasn't been brought out of the reset > > state yet since the function zynqmp_dp_reset(dp, false) is called later and > > this will result the system hang. > > > > Releasing the reset to DP controller before any read/write operation to it > > will fix this issue. And for symmetry, move zynqmp_dp_reset() call from > > zynqmp_dp_phy_exit() to zynqmp_dp_remove(). > > > > Signed-off-by: Quanyang Wang > > Reviewed-by: Laurent Pinchart Can someone pick this patch? Thanks, Michal
Re: [PATCH] drm/lima: Convert to clk_bulk API
On 7/18/21 4:56 AM, Qiang Yu wrote:
> On Sat, Jul 17, 2021 at 10:52 PM Marek Vasut wrote:
>>
>> On 7/17/21 4:21 PM, Qiang Yu wrote:
>>> On Sat, Jul 17, 2021 at 9:08 PM Marek Vasut wrote:
On 7/17/21 2:34 PM, Qiang Yu wrote:
> On Sat, Jul 17, 2021 at 2:20 AM Marek Vasut wrote:
>>
>> Instead of requesting two separate clock and then handling them
>> separately in various places of the driver, use clk_bulk_*() API.
>> This permits handling devices with more than "bus"/"core" clock,
>> like ZynqMP, which has "gpu"/"gpu_pp0"/"gpu_pp1" all as separate
>> clock.
>
> I can't find the ZynqMP DTS file under arch/arm64/boot/dts/xilinx
> which has mali GPU node with an upstream kernel, where is it?
Posted here:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210716182544.219490-1-ma...@denx.de/
> So what's the relationship between "gpu" clk and "gpu_pp0"/"gpu_pp1"
> clk? Do they need to be controlled separately or we can just control the
> "gpu" clk? Because the devfreq code just controls a single module clk.
Per the docs, they are separate enable bits and the zynqmp clock
controller exports them as separate clock, see bits 24..26 here:
https://www.xilinx.com/html_docs/registers/ug1087/crf_apb___gpu_ref_ctrl.html
>> Signed-off-by: Marek Vasut
>> Cc: Qiang Yu
>> Cc: l...@lists.freedesktop.org
>> ---
>>drivers/gpu/drm/lima/lima_devfreq.c | 17 +---
>>drivers/gpu/drm/lima/lima_devfreq.h | 1 +
>>drivers/gpu/drm/lima/lima_device.c | 42 +++--
>>drivers/gpu/drm/lima/lima_device.h | 4 +--
>>4 files changed, 32 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
>> b/drivers/gpu/drm/lima/lima_devfreq.c
>> index 8989e215dfc9..533b36932f79 100644
>> --- a/drivers/gpu/drm/lima/lima_devfreq.c
>> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
>> @@ -58,7 +58,7 @@ static int lima_devfreq_get_dev_status(struct device
>> *dev,
>> struct lima_devfreq *devfreq = >devfreq;
>> unsigned long irqflags;
>>
>> - status->current_frequency = clk_get_rate(ldev->clk_gpu);
>> + status->current_frequency = clk_get_rate(devfreq->clk_gpu);
>>
>> spin_lock_irqsave(>lock, irqflags);
>>
>> @@ -110,12 +110,23 @@ int lima_devfreq_init(struct lima_device *ldev)
>> struct lima_devfreq *ldevfreq = >devfreq;
>> struct dev_pm_opp *opp;
>> unsigned long cur_freq;
>> - int ret;
>> + int i, ret;
>>
>> if (!device_property_present(dev, "operating-points-v2"))
>> /* Optional, continue without devfreq */
>> return 0;
>>
>> + /* Find first clock which are not "bus" clock */
>> + for (i = 0; i < ldev->nr_clks; i++) {
>> + if (!strcmp(ldev->clks[i].id, "bus"))
>> + continue;
>> + ldevfreq->clk_gpu = ldev->clks[i].clk;
>> + break;
>> + }
>
> I'd prefer an explicit name for the required clk name. If some DTS has
> different
> name other than "core" for the module clk (ie. "gpu"), it should be
> changed to
> "core".
The problem here is, the zynqmp has no core clock, it has "gpu and both
pixel pipes" super-clock-gate which controls everything, and then
per-pixel-pipe sub-clock-gates.
>>>
>>> So the "gpu" clk can gate both "gpu_pp0" and "gpu_pp1" clk, how about
>>> frequency?
>>
>> I don't think it is a good idea to just gate off the root clock while
>> the sub-clock are still enabled. That might lead to latch ups (+CC
>> Michal, he might know more).
>>
>> And who would enable the sub-clock anyway, it should be the GPU driver, no?
>>
> Right, I understand it's not proper either by HW or SW point of view to just
> use root clk gate.
>
>>> Can we set clock rate for "gpu" then "gpu_pp0" and "gpu_pp1" pass
>>> through the same
>>> rate? If so, "gpu" works just like "core".
>>
>> I don't think the zynqmp is capable of any DVFS on the GPU at all, it
>> just runs at fixed frequency.
>
> I see the GPU_REF_CTRL register 13:8 is a divisor, is this for all
> "gpu"/"gpu_pp0"/"gpu_pp1" clk rating? If so, can we use it to dynamically
> change the GPU clk freq because other SoC also use system clock
> to do GPU DVFS, see sun8i-h3.dtsi. If we can't then zynqmp won't finish
> lima_devfreq_init() and get here at all because it does not have
> an OPP table.
>
Jianqiang: Please take a look at this from zynqmp point of view.
Thanks,
Michal
Re: [PATCH] drm: xlnx: zynqmp: fix a memset in zynqmp_dp_train()
On 3/30/21 11:31 AM, Dan Carpenter wrote:
> The dp->train_set[] for this driver is only two characters, not four so
> this memsets too much. Fortunately, this ends up corrupting a struct
> hole and not anything important.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 99158ee67d02..59d1fb017da0 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -866,7 +866,7 @@ static int zynqmp_dp_train(struct zynqmp_dp *dp)
> return ret;
>
> zynqmp_dp_write(dp, ZYNQMP_DP_SCRAMBLING_DISABLE, 1);
> - memset(dp->train_set, 0, 4);
> + memset(dp->train_set, 0, sizeof(dp->train_set));
> ret = zynqmp_dp_link_train_cr(dp);
> if (ret)
> return ret;
>
Reviewed-by: Michal Simek
Thanks,
Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: xlnx: call pm_runtime_get_sync before setting pixel clock
+Rohit On 3/17/21 4:00 AM, quanyang.wang wrote: > Hi Laurent, > > On 3/17/21 4:32 AM, Laurent Pinchart wrote: >> Hi Quanyang, >> >> Thank you for the patch. >> >> On Wed, Mar 10, 2021 at 12:59:45PM +0800, quanyang.w...@windriver.com >> wrote: >>> From: Quanyang Wang >>> >>> The Runtime PM subsystem will force the device "fd4a.zynqmp-display" >>> to enter suspend state while booting if the following conditions are >>> met: >>> - the usage counter is zero (pm_runtime_get_sync hasn't been called yet) >>> - no 'active' children (no zynqmp-dp-snd-xx node under dpsub node) >>> - no other device in the same power domain (dpdma node has no >>> "power-domains = <_firmware PD_DP>" property) >>> >>> So there is a scenario as below: >>> 1) DP device enters suspend state <- call zynqmp_gpd_power_off >>> 2) zynqmp_disp_crtc_setup_clock <- configurate register >>> VPLL_FRAC_CFG >>> 3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and >>> clear previous >>> VPLL_FRAC_CFG configuration >>> 4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG >>> configuration is corrupted >>> >>> From above, we can see that pm_runtime_get_sync may clear register >>> VPLL_FRAC_CFG configuration and result the failure of clk enabling. >>> Putting pm_runtime_get_sync at the very beginning of the function >>> zynqmp_disp_crtc_atomic_enable can resolve this issue. >> Isn't this an issue in the firmware though, which shouldn't clear the >> previous VPLLF_FRAC_CFG ? > > Thank you for your review. I used to look into the atf and PWU code and > it seems (I didn't add debug code > > to PMU to make sure if PMU really does this, I only in kernel call > zynqmp_pm_get_pll_frac_data to make sure that > > the value in data field of VPLL_FRAC_CFG register is changed from 0x4000 > to 0x0 after run pm_runtime_get_sync) > > that PMU intends to reset VPLL when there is an Off and On in DP > Powerdomain. > > > Linux ATF PWU > > zynqmp_gpd_power_on > ->zynqmp_pm_set_requirement > -->send PM_SET_REQUIREMENT to ATF ==> ATF send ipi to PWU > ==> PmSetRequirement > ->PmRequirementUpdate > -->PmUpdateSlave(masterReq->slave) > --->PmSlaveChangeState > >PmSlaveChangeState > ->PmSlaveClearAfterState > -->PmClockRelease > > --->PmClockReleaseInt(>clock->base) > >clk->class->release(clk) > ->PmPllBypassAndReset > //Here reset the VPLL then VPLL_FRAC_CFG is cleared. > >> >>> Signed-off-by: Quanyang Wang >> Nonetheless, this change looks good to me, I actually had the same patch >> in my tree while investigation issues related to the clock rate, so >> >> Reviewed-by: Laurent Pinchart >> Tested-by: Laurent Pinchart >> >> I was hoping it would solve the issue I'm experiencing with the DP >> clock, but that's not the case :-( In a nutshell, when the DP is first >> started, the clock frequency is incorrect. The following quick & dirty >> patch fixes the problem: >> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c >> b/drivers/gpu/drm/xlnx/zynqmp_disp.c >> index 74ac0a064eb5..fdbe1b0640aa 100644 >> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c >> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c >> @@ -1439,6 +1439,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc >> *crtc, >> >> pm_runtime_get_sync(disp->dev); >> >> + ret = clk_prepare_enable(disp->pclk); >> + if (!ret) >> + clk_disable_unprepare(disp->pclk); >> + >> zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode); >> >> ret = clk_prepare_enable(disp->pclk); >> >> The problem doesn't seem to be in the kernel, but on the TF-A or PMU >> firmware side. Have you experienced this by any chance ? > > Yes, I bumped into the same issue and I used to make a patch (Patch 1) > as below. > > I didn't send it to mainline because it seems not to be a driver issue. > The mode of VPLL > > is not set correctly because: > > 1) VPLL is enabled before linux > > 2) linux calling pm_clock_set_pll_mode can't really set register because > in ATF > > it only store the mode value to a structure and wait a clk-enable > request to do > > the register-set operation. > > 3) linux call clk_enable will not send a clk-enable request since it > checks that > > the VPLL is already hardware-enabled because of 1). > > So the firmware should disable VPLL when it exits and also in linux > zynqmp clk driver > > there should be a check list to reset some clks to a predefined state. > > > By the way, there is a tiny patch (Patch 2) to fix the black screen > issue in DP. I think you may > > be preparing a big
Re: [PATCH] dt-bindings: Fix 'reg' size issues in zynqmp examples
On 29. 09. 20 16:55, Rob Herring wrote:
> On Tue, Sep 29, 2020 at 1:55 AM Michal Simek wrote:
>>
>> Hi Rob,
>>
>> On 28. 09. 20 17:59, Rob Herring wrote:
>>> The default sizes in examples for 'reg' are 1 cell each. Fix the
>>> incorrect sizes in zynqmp examples:
>>>
>>> Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.example.dt.yaml:
>>> example-0: dma-controller@fd4c:reg:0: [0, 4249616384, 0, 4096] is too
>>> long
>>> From schema:
>>> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>>> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>>> example-0: display@fd4a:reg:0: [0, 4249485312, 0, 4096] is too long
>>> From schema:
>>> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>>> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>>> example-0: display@fd4a:reg:1: [0, 4249526272, 0, 4096] is too long
>>> From schema:
>>> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>>> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>>> example-0: display@fd4a:reg:2: [0, 4249530368, 0, 4096] is too long
>>> From schema:
>>> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>>> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>>> example-0: display@fd4a:reg:3: [0, 4249534464, 0, 4096] is too long
>>> From schema:
>>> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>>>
>>> Cc: Hyun Kwon
>>> Cc: Laurent Pinchart
>>> Cc: Michal Simek
>>> Cc: Vinod Koul
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: dmaeng...@vger.kernel.org
>>> Signed-off-by: Rob Herring
>>> ---
>>> .../bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 8
>>> .../devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml | 2 +-
>>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
>>> b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
>>> index 52a939cade3b..7b9d468c3e52 100644
>>> --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
>>> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
>>> @@ -145,10 +145,10 @@ examples:
>>>
>>> display@fd4a {
>>> compatible = "xlnx,zynqmp-dpsub-1.7";
>>> -reg = <0x0 0xfd4a 0x0 0x1000>,
>>> - <0x0 0xfd4aa000 0x0 0x1000>,
>>> - <0x0 0xfd4ab000 0x0 0x1000>,
>>> - <0x0 0xfd4ac000 0x0 0x1000>;
>>> +reg = <0xfd4a 0x1000>,
>>> + <0xfd4aa000 0x1000>,
>>> + <0xfd4ab000 0x1000>,
>>> + <0xfd4ac000 0x1000>;
>>> reg-names = "dp", "blend", "av_buf", "aud";
>>> interrupts = <0 119 4>;
>>> interrupt-parent = <>;
>>> diff --git
>>> a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
>>> b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
>>> index 5de510f8c88c..2a595b18ff6c 100644
>>> --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
>>> +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
>>> @@ -57,7 +57,7 @@ examples:
>>>
>>> dma: dma-controller@fd4c {
>>>compatible = "xlnx,zynqmp-dpdma";
>>> - reg = <0x0 0xfd4c 0x0 0x1000>;
>>> + reg = <0xfd4c 0x1000>;
>>>interrupts = ;
>>>interrupt-parent = <>;
>>>clocks = <_clk>;
>>>
>>
>> I would prefer to keep 64bit version.
>> I use this style.
>
> I prefer to keep the examples simple. The address size is outside the
> scope of the binding.
ok.
Acked-by: Michal Simek
Thanks,
Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Fix 'reg' size issues in zynqmp examples
Hi Rob,
On 28. 09. 20 17:59, Rob Herring wrote:
> The default sizes in examples for 'reg' are 1 cell each. Fix the
> incorrect sizes in zynqmp examples:
>
> Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.example.dt.yaml:
> example-0: dma-controller@fd4c:reg:0: [0, 4249616384, 0, 4096] is too
> long
> From schema:
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
> example-0: display@fd4a:reg:0: [0, 4249485312, 0, 4096] is too long
> From schema:
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
> example-0: display@fd4a:reg:1: [0, 4249526272, 0, 4096] is too long
> From schema:
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
> example-0: display@fd4a:reg:2: [0, 4249530368, 0, 4096] is too long
> From schema:
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
> example-0: display@fd4a:reg:3: [0, 4249534464, 0, 4096] is too long
> From schema:
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
>
> Cc: Hyun Kwon
> Cc: Laurent Pinchart
> Cc: Michal Simek
> Cc: Vinod Koul
> Cc: dri-devel@lists.freedesktop.org
> Cc: dmaeng...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> .../bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 8
> .../devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> index 52a939cade3b..7b9d468c3e52 100644
> --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> @@ -145,10 +145,10 @@ examples:
>
> display@fd4a {
> compatible = "xlnx,zynqmp-dpsub-1.7";
> -reg = <0x0 0xfd4a 0x0 0x1000>,
> - <0x0 0xfd4aa000 0x0 0x1000>,
> - <0x0 0xfd4ab000 0x0 0x1000>,
> - <0x0 0xfd4ac000 0x0 0x1000>;
> +reg = <0xfd4a 0x1000>,
> + <0xfd4aa000 0x1000>,
> + <0xfd4ab000 0x1000>,
> + <0xfd4ac000 0x1000>;
> reg-names = "dp", "blend", "av_buf", "aud";
> interrupts = <0 119 4>;
> interrupt-parent = <>;
> diff --git
> a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
> b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
> index 5de510f8c88c..2a595b18ff6c 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
> @@ -57,7 +57,7 @@ examples:
>
> dma: dma-controller@fd4c {
>compatible = "xlnx,zynqmp-dpdma";
> - reg = <0x0 0xfd4c 0x0 0x1000>;
> + reg = <0xfd4c 0x1000>;
>interrupts = ;
>interrupt-parent = <>;
>clocks = <_clk>;
>
I would prefer to keep 64bit version.
I use this style.
bus {
#address-cells = <2>;
#size-cells = <2>;
...
};
Thanks,
Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 03. 06. 20 10:13, Christophe Leroy wrote: > Hi, > > Le 03/06/2020 à 10:10, Michal Simek a écrit : >> Hi Michael, >> >> On 26. 05. 20 15:44, Michael Ellerman wrote: >>> Michal Simek writes: >>>> Hi Michael, >>>> >>>> On 01. 04. 20 13:30, Michal Simek wrote: >>>>> On 01. 04. 20 12:38, Takashi Iwai wrote: >>>>>> On Wed, 01 Apr 2020 12:35:16 +0200, >>>>>> Michael Ellerman wrote: >>>>>>> >>>>>>> Michal Simek writes: >>>>>>>> On 01. 04. 20 4:07, Michael Ellerman wrote: >>>>>>>>> Michal Simek writes: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> recently we wanted to update xilinx intc driver and we found >>>>>>>>>> that function >>>>>>>>>> which we wanted to remove is still wired by ancient Xilinx >>>>>>>>>> PowerPC >>>>>>>>>> platforms. Here is the thread about it. >>>>>>>>>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have been talking about it internally and there is no >>>>>>>>>> interest in these >>>>>>>>>> platforms and it is also orphan for quite a long time. None is >>>>>>>>>> really >>>>>>>>>> running/testing these platforms regularly that's why I think >>>>>>>>>> it makes sense >>>>>>>>>> to remove them also with drivers which are specific to this >>>>>>>>>> platform. >>>>>>>>>> >>>>>>>>>> U-Boot support was removed in 2017 without anybody complain >>>>>>>>>> about it >>>>>>>>>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Based on current ppc/next. >>>>>>>>>> >>>>>>>>>> If anyone has any objection about it, please let me know. >>>>>>>>> >>>>>>>>> Thanks for taking the time to find all this code and remove it. >>>>>>>>> >>>>>>>>> I'm not going to take this series for v5.7, it was posted too >>>>>>>>> close to >>>>>>>>> the merge window, and doing so wouldn't give people much time >>>>>>>>> to object, >>>>>>>>> especially given people are distracted at the moment. >>>>>>>>> >>>>>>>>> I'm happy to take it for v5.8, assuming there's no major >>>>>>>>> objections. >>>>>>>> >>>>>>>> Sure. Just to let you know Christophe Leroy included this patch >>>>>>>> in his >>>>>>>> series about ppc405 removal. It should be the same. >>>>>>>> >>>>>>>> If you don't want to take that alsa patch I can send it >>>>>>>> separately and >>>>>>>> this patch can be taken from his series. I don't really mind but >>>>>>>> please >>>>>>>> let me know what way you prefer. >>>>>>> >>>>>>> It's better to keep it all together, so I'm happy take the alsa >>>>>>> patch as >>>>>>> well, it's already been acked. >>>> >>>> Can you please take this series? I know that there is v5 from >>>> Christophe >>>> which has this 1/2 as 1/13. But I need this alsa patch too and I would >>>> like to close this because it is around for almost 2 months and none >>>> raised a concern about removing just these Xilinx platforms. >>> >>> Sorry I meant to reply to your last mail. >>> >>> I have Christophe's series in my testing branch, planning for it to be >>> in v5.8. >>> >>> Even if the rest of his series doesn't make it for some reason, as you >>> say the Xilinx removal is uncontroversial so I'll keep that in. >>> >>> I forgot about the sound patch, I'll pick that up as well. >> >> I took a look at your >> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git repo >> and I can't see any branch with my patches. >> Also was checking linux-next and my patches are also not there. >> That's why I am curious if this will be go v5.8 in MW. > > I see them in > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git in > next-test branch. ah. My bad. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi Michael, On 26. 05. 20 15:44, Michael Ellerman wrote: > Michal Simek writes: >> Hi Michael, >> >> On 01. 04. 20 13:30, Michal Simek wrote: >>> On 01. 04. 20 12:38, Takashi Iwai wrote: >>>> On Wed, 01 Apr 2020 12:35:16 +0200, >>>> Michael Ellerman wrote: >>>>> >>>>> Michal Simek writes: >>>>>> On 01. 04. 20 4:07, Michael Ellerman wrote: >>>>>>> Michal Simek writes: >>>>>>>> Hi, >>>>>>>> >>>>>>>> recently we wanted to update xilinx intc driver and we found that >>>>>>>> function >>>>>>>> which we wanted to remove is still wired by ancient Xilinx PowerPC >>>>>>>> platforms. Here is the thread about it. >>>>>>>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >>>>>>>> >>>>>>>> I have been talking about it internally and there is no interest in >>>>>>>> these >>>>>>>> platforms and it is also orphan for quite a long time. None is really >>>>>>>> running/testing these platforms regularly that's why I think it makes >>>>>>>> sense >>>>>>>> to remove them also with drivers which are specific to this platform. >>>>>>>> >>>>>>>> U-Boot support was removed in 2017 without anybody complain about it >>>>>>>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >>>>>>>> >>>>>>>> Based on current ppc/next. >>>>>>>> >>>>>>>> If anyone has any objection about it, please let me know. >>>>>>> >>>>>>> Thanks for taking the time to find all this code and remove it. >>>>>>> >>>>>>> I'm not going to take this series for v5.7, it was posted too close to >>>>>>> the merge window, and doing so wouldn't give people much time to object, >>>>>>> especially given people are distracted at the moment. >>>>>>> >>>>>>> I'm happy to take it for v5.8, assuming there's no major objections. >>>>>> >>>>>> Sure. Just to let you know Christophe Leroy included this patch in his >>>>>> series about ppc405 removal. It should be the same. >>>>>> >>>>>> If you don't want to take that alsa patch I can send it separately and >>>>>> this patch can be taken from his series. I don't really mind but please >>>>>> let me know what way you prefer. >>>>> >>>>> It's better to keep it all together, so I'm happy take the alsa patch as >>>>> well, it's already been acked. >> >> Can you please take this series? I know that there is v5 from Christophe >> which has this 1/2 as 1/13. But I need this alsa patch too and I would >> like to close this because it is around for almost 2 months and none >> raised a concern about removing just these Xilinx platforms. > > Sorry I meant to reply to your last mail. > > I have Christophe's series in my testing branch, planning for it to be > in v5.8. > > Even if the rest of his series doesn't make it for some reason, as you > say the Xilinx removal is uncontroversial so I'll keep that in. > > I forgot about the sound patch, I'll pick that up as well. I took a look at your https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git repo and I can't see any branch with my patches. Also was checking linux-next and my patches are also not there. That's why I am curious if this will be go v5.8 in MW. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi Michael, On 01. 04. 20 13:30, Michal Simek wrote: > On 01. 04. 20 12:38, Takashi Iwai wrote: >> On Wed, 01 Apr 2020 12:35:16 +0200, >> Michael Ellerman wrote: >>> >>> Michal Simek writes: >>>> On 01. 04. 20 4:07, Michael Ellerman wrote: >>>>> Michal Simek writes: >>>>>> Hi, >>>>>> >>>>>> recently we wanted to update xilinx intc driver and we found that >>>>>> function >>>>>> which we wanted to remove is still wired by ancient Xilinx PowerPC >>>>>> platforms. Here is the thread about it. >>>>>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >>>>>> >>>>>> I have been talking about it internally and there is no interest in these >>>>>> platforms and it is also orphan for quite a long time. None is really >>>>>> running/testing these platforms regularly that's why I think it makes >>>>>> sense >>>>>> to remove them also with drivers which are specific to this platform. >>>>>> >>>>>> U-Boot support was removed in 2017 without anybody complain about it >>>>>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >>>>>> >>>>>> Based on current ppc/next. >>>>>> >>>>>> If anyone has any objection about it, please let me know. >>>>> >>>>> Thanks for taking the time to find all this code and remove it. >>>>> >>>>> I'm not going to take this series for v5.7, it was posted too close to >>>>> the merge window, and doing so wouldn't give people much time to object, >>>>> especially given people are distracted at the moment. >>>>> >>>>> I'm happy to take it for v5.8, assuming there's no major objections. >>>> >>>> Sure. Just to let you know Christophe Leroy included this patch in his >>>> series about ppc405 removal. It should be the same. >>>> >>>> If you don't want to take that alsa patch I can send it separately and >>>> this patch can be taken from his series. I don't really mind but please >>>> let me know what way you prefer. >>> >>> It's better to keep it all together, so I'm happy take the alsa patch as >>> well, it's already been acked. >> >> Sure, please go ahead. > > > g8. Can you please take this series? I know that there is v5 from Christophe which has this 1/2 as 1/13. But I need this alsa patch too and I would like to close this because it is around for almost 2 months and none raised a concern about removing just these Xilinx platforms. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 21. 05. 20 15:53, Michael Ellerman wrote: > Christophe Leroy writes: >> Le 21/05/2020 à 09:02, Michael Ellerman a écrit : >>> Arnd Bergmann writes: +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote: > Benjamin Herrenschmidt writes: >> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >>> Benjamin Herrenschmidt writes: >> IBM still put 40x cores inside POWER chips no ? > > Oh yeah that's true. I guess most folks don't know that, or that they > run RHEL on them. Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels. >>> >>> Sorry that part was a joke :D Those chips don't run Linux. >>> >> >> Nice to know :) >> >> What's the plan then, do we still want to keep 40x in the kernel ? > > I guess we keep it for now. > > Perhaps we mark it BROKEN for a few releases and see if anyone > complains? I would like to get at least that xilinx patch to the tree to unblock our changes on interrupt controller. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 01. 04. 20 12:38, Takashi Iwai wrote: > On Wed, 01 Apr 2020 12:35:16 +0200, > Michael Ellerman wrote: >> >> Michal Simek writes: >>> On 01. 04. 20 4:07, Michael Ellerman wrote: >>>> Michal Simek writes: >>>>> Hi, >>>>> >>>>> recently we wanted to update xilinx intc driver and we found that function >>>>> which we wanted to remove is still wired by ancient Xilinx PowerPC >>>>> platforms. Here is the thread about it. >>>>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >>>>> >>>>> I have been talking about it internally and there is no interest in these >>>>> platforms and it is also orphan for quite a long time. None is really >>>>> running/testing these platforms regularly that's why I think it makes >>>>> sense >>>>> to remove them also with drivers which are specific to this platform. >>>>> >>>>> U-Boot support was removed in 2017 without anybody complain about it >>>>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >>>>> >>>>> Based on current ppc/next. >>>>> >>>>> If anyone has any objection about it, please let me know. >>>> >>>> Thanks for taking the time to find all this code and remove it. >>>> >>>> I'm not going to take this series for v5.7, it was posted too close to >>>> the merge window, and doing so wouldn't give people much time to object, >>>> especially given people are distracted at the moment. >>>> >>>> I'm happy to take it for v5.8, assuming there's no major objections. >>> >>> Sure. Just to let you know Christophe Leroy included this patch in his >>> series about ppc405 removal. It should be the same. >>> >>> If you don't want to take that alsa patch I can send it separately and >>> this patch can be taken from his series. I don't really mind but please >>> let me know what way you prefer. >> >> It's better to keep it all together, so I'm happy take the alsa patch as >> well, it's already been acked. > > Sure, please go ahead. g8. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 01. 04. 20 4:07, Michael Ellerman wrote: > Michal Simek writes: >> Hi, >> >> recently we wanted to update xilinx intc driver and we found that function >> which we wanted to remove is still wired by ancient Xilinx PowerPC >> platforms. Here is the thread about it. >> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >> >> I have been talking about it internally and there is no interest in these >> platforms and it is also orphan for quite a long time. None is really >> running/testing these platforms regularly that's why I think it makes sense >> to remove them also with drivers which are specific to this platform. >> >> U-Boot support was removed in 2017 without anybody complain about it >> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >> >> Based on current ppc/next. >> >> If anyone has any objection about it, please let me know. > > Thanks for taking the time to find all this code and remove it. > > I'm not going to take this series for v5.7, it was posted too close to > the merge window, and doing so wouldn't give people much time to object, > especially given people are distracted at the moment. > > I'm happy to take it for v5.8, assuming there's no major objections. Sure. Just to let you know Christophe Leroy included this patch in his series about ppc405 removal. It should be the same. If you don't want to take that alsa patch I can send it separately and this patch can be taken from his series. I don't really mind but please let me know what way you prefer. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 31. 03. 20 11:49, Christophe Leroy wrote: > > > Le 31/03/2020 à 09:19, Christophe Leroy a écrit : >> >> >> Le 31/03/2020 à 08:59, Michal Simek a écrit : >>> On 31. 03. 20 8:56, Christophe Leroy wrote: >>>> >>>> >>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >>>>> Christophe Leroy writes: >>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>>>>> wrote: >>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>>>>> wrote: >>>>>>> ... >>>>>>> >>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>>>>> time to >>>>>>>>>>> retire all of it? >>>>>>>>>> >>>>>>>>>> Who knows? >>>>>>>>>> >>>>>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>>>>> architecture, and I >>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>>>>> amount of real >>>>>>>>>> users not too big. >>>>>>>>> >>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>>>>> >>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>>>>> based on >>>>>>>> APM82181/ppc464, so it is about several generations newer than >>>>>>>> what I >>>>>>>> asked about (ppc40x). >>>>>>>> >>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>>>>> testing, so, >>>>>>>>>> I don't care much. >>>>>>>> >>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>>>>> not 405 >>>>>>>> to my knowledge. >>>>>>> >>>>>>> Ah, you are right. No objections from ppc40x removal! >>>>>> >>>>>> Removing 40x would help cleaning things a bit. For instance 40x is >>>>>> the >>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove >>>>>> 40x >>>>>> we can get rid of PTE_ATOMIC_UPDATES completely. >>>>>> >>>>>> If no one objects, I can prepare a series to drop support for 40x >>>>>> completely. >>>>>> >>>>>> Michael, any thought ? >>>>> >>>>> I have no attachment to 40x, and I'd certainly be happy to have less >>>>> code in the tree, we struggle to keep even the modern platforms well >>>>> maintained. >>>>> >>>>> At the same time I don't want to render anyone's hardware obsolete >>>>> unnecessarily. But if there's really no one using 40x then we should >>>>> remove it, it could well be broken already. >>>>> >>>>> So I guess post a series to do the removal and we'll see if anyone >>>>> speaks up. >>>>> >>>> >>>> Ok, series sent out, see >>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >>> >>> ok. I see you have done it completely independently of my patchset. >>> Would be better if you can base it on the top of my 2 patches because >>> they are in conflict now and I need to also remove virtex 44x platform >>> also with alsa driver. >>> >> >> I can't see your first patch, only the second one shows up in the >> series, see >> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >> > > > Ok, I found your first patch on another patchwork, it doesn't touch any > file in arch/powerpc/ There was just driver dependency on symbol which is removed by 2/2. Let's see what you get from kbuild if any symbol is removed but still used in drivers folder. > > I sent a v2 series with your powerpc patch as patch 2/11 > > See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766 Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
On 31. 03. 20 8:56, Christophe Leroy wrote: > > > Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >> Christophe Leroy writes: >>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>> wrote: >>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>> wrote: >>>> ... >>>> >>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>> time to >>>>>>>> retire all of it? >>>>>>> >>>>>>> Who knows? >>>>>>> >>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>> architecture, and I >>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>> amount of real >>>>>>> users not too big. >>>>>> >>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>> >>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>> based on >>>>> APM82181/ppc464, so it is about several generations newer than what I >>>>> asked about (ppc40x). >>>>> >>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>> testing, so, >>>>>>> I don't care much. >>>>> >>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>> not 405 >>>>> to my knowledge. >>>> >>>> Ah, you are right. No objections from ppc40x removal! >>> >>> Removing 40x would help cleaning things a bit. For instance 40x is the >>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x >>> we can get rid of PTE_ATOMIC_UPDATES completely. >>> >>> If no one objects, I can prepare a series to drop support for 40x >>> completely. >>> >>> Michael, any thought ? >> >> I have no attachment to 40x, and I'd certainly be happy to have less >> code in the tree, we struggle to keep even the modern platforms well >> maintained. >> >> At the same time I don't want to render anyone's hardware obsolete >> unnecessarily. But if there's really no one using 40x then we should >> remove it, it could well be broken already. >> >> So I guess post a series to do the removal and we'll see if anyone >> speaks up. >> > > Ok, series sent out, see > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi, recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform. U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed Based on current ppc/next. If anyone has any objection about it, please let me know. Thanks, Michal Changes in v2: - Remove also sound/drivers/pcm-indirect2.[ch] files Reported-by: Takashi Iwai - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in v1 to keep them the same as before. (kbuild reported some issues with it too) Michal Simek (2): sound: ac97: Remove sound driver for ancient platform powerpc: Remove Xilinx PPC405/PPC440 support Documentation/devicetree/bindings/xilinx.txt | 143 -- Documentation/powerpc/bootwrapper.rst| 28 +- MAINTAINERS |6 - arch/powerpc/Kconfig.debug |2 +- arch/powerpc/boot/Makefile |7 +- arch/powerpc/boot/dts/Makefile |1 - arch/powerpc/boot/dts/virtex440-ml507.dts| 406 -- arch/powerpc/boot/dts/virtex440-ml510.dts| 466 --- arch/powerpc/boot/ops.h |1 - arch/powerpc/boot/serial.c |5 - arch/powerpc/boot/uartlite.c | 79 -- arch/powerpc/boot/virtex.c | 97 -- arch/powerpc/boot/virtex405-head.S | 31 - arch/powerpc/boot/wrapper|8 - arch/powerpc/configs/40x/virtex_defconfig| 75 - arch/powerpc/configs/44x/virtex5_defconfig | 74 - arch/powerpc/configs/ppc40x_defconfig|8 - arch/powerpc/configs/ppc44x_defconfig|8 - arch/powerpc/include/asm/xilinx_intc.h | 16 - arch/powerpc/include/asm/xilinx_pci.h| 21 - arch/powerpc/kernel/cputable.c | 39 - arch/powerpc/platforms/40x/Kconfig | 31 - arch/powerpc/platforms/40x/Makefile |1 - arch/powerpc/platforms/40x/virtex.c | 54 - arch/powerpc/platforms/44x/Kconfig | 37 - arch/powerpc/platforms/44x/Makefile |2 - arch/powerpc/platforms/44x/virtex.c | 60 - arch/powerpc/platforms/44x/virtex_ml510.c| 30 - arch/powerpc/platforms/Kconfig |4 - arch/powerpc/sysdev/Makefile |2 - arch/powerpc/sysdev/xilinx_intc.c| 88 -- arch/powerpc/sysdev/xilinx_pci.c | 132 -- drivers/char/Kconfig |2 +- drivers/video/fbdev/Kconfig |2 +- sound/drivers/Kconfig| 12 - sound/drivers/Makefile |2 - sound/drivers/ml403-ac97cr.c | 1298 -- sound/drivers/pcm-indirect2.c| 560 sound/drivers/pcm-indirect2.h| 127 -- 39 files changed, 7 insertions(+), 3958 deletions(-) delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts delete mode 100644 arch/powerpc/boot/uartlite.c delete mode 100644 arch/powerpc/boot/virtex.c delete mode 100644 arch/powerpc/boot/virtex405-head.S delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h delete mode 100644 arch/powerpc/platforms/40x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c delete mode 100644 sound/drivers/ml403-ac97cr.c delete mode 100644 sound/drivers/pcm-indirect2.c delete mode 100644 sound/drivers/pcm-indirect2.h -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
The latest Xilinx design tools called ISE and EDK has been released in
October 2013. New tool doesn't support any PPC405/PPC440 new designs.
These platforms are no longer supported and tested.
PowerPC 405/440 port is orphan from 2013 by
commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
maintainership")
that's why it is time to remove the support fot these platforms.
Signed-off-by: Michal Simek
Acked-by: Arnd Bergmann
---
Changes in v2:
- Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
v1 to keep them the same as before. (kbuild reported some issues with it
too)
Documentation/devicetree/bindings/xilinx.txt | 143 --
Documentation/powerpc/bootwrapper.rst| 28 +-
MAINTAINERS | 6 -
arch/powerpc/Kconfig.debug | 2 +-
arch/powerpc/boot/Makefile | 7 +-
arch/powerpc/boot/dts/Makefile | 1 -
arch/powerpc/boot/dts/virtex440-ml507.dts| 406
arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
arch/powerpc/boot/ops.h | 1 -
arch/powerpc/boot/serial.c | 5 -
arch/powerpc/boot/uartlite.c | 79
arch/powerpc/boot/virtex.c | 97
arch/powerpc/boot/virtex405-head.S | 31 --
arch/powerpc/boot/wrapper| 8 -
arch/powerpc/configs/40x/virtex_defconfig| 75 ---
arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
arch/powerpc/configs/ppc40x_defconfig| 8 -
arch/powerpc/configs/ppc44x_defconfig| 8 -
arch/powerpc/include/asm/xilinx_intc.h | 16 -
arch/powerpc/include/asm/xilinx_pci.h| 21 -
arch/powerpc/kernel/cputable.c | 39 --
arch/powerpc/platforms/40x/Kconfig | 31 --
arch/powerpc/platforms/40x/Makefile | 1 -
arch/powerpc/platforms/40x/virtex.c | 54 ---
arch/powerpc/platforms/44x/Kconfig | 37 --
arch/powerpc/platforms/44x/Makefile | 2 -
arch/powerpc/platforms/44x/virtex.c | 60 ---
arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
arch/powerpc/platforms/Kconfig | 4 -
arch/powerpc/sysdev/Makefile | 2 -
arch/powerpc/sysdev/xilinx_intc.c| 88
arch/powerpc/sysdev/xilinx_pci.c | 132 --
drivers/char/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
34 files changed, 7 insertions(+), 1959 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
delete mode 100644 arch/powerpc/boot/uartlite.c
delete mode 100644 arch/powerpc/boot/virtex.c
delete mode 100644 arch/powerpc/boot/virtex405-head.S
delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
delete mode 100644 arch/powerpc/platforms/40x/virtex.c
delete mode 100644 arch/powerpc/platforms/44x/virtex.c
delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/Documentation/devicetree/bindings/xilinx.txt
b/Documentation/devicetree/bindings/xilinx.txt
index d058ace29345..28199b31fe5e 100644
--- a/Documentation/devicetree/bindings/xilinx.txt
+++ b/Documentation/devicetree/bindings/xilinx.txt
@@ -86,149 +86,6 @@
xlnx,use-parity = <0>;
};
- Some IP cores actually implement 2 or more logical devices. In
- this case, the device should still describe the whole IP core with
- a single node and add a child node for each logical device. The
- ranges property can be used to translate from parent IP-core to the
- registers of each device. In addition, the parent node should be
- compatible with the bus type 'xlnx,compound', and should contain
- #address-cells and #size-cells, as with any other bus. (Note: this
- makes the assumption that both logical devices have the same bus
- binding. If this is not true, then separate nodes should be used
- for each logical device). The 'cell-index' property can be used to
- enumerate logical devices within an IP core. For example, the
- following is the system.mhs entry for the dual ps2 controller found
- on the ml403 reference design.
-
- BEGIN opb_ps2_dual_ref
- PARAMETER INSTANCE = opb_ps2_dual_ref_0
- PARAMETER HW_VER = 1.00.a
- PARAMETER C_BASEADDR = 0xA900
- PARAMETER C_HIGHADDR = 0xA9001FFF
- BUS_INTERFACE SOPB = opb_v20_0
- PORT Sys_Intr1 = ps2_1_intr
-
[PATCH 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
The latest Xilinx design tools called ISE and EDK has been released in
October 2013. New tool doesn't support any PPC405/PPC440 new designs.
These platforms are no longer supported and tested.
PowerPC 405/440 port is orphan from 2013 by
commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
maintainership")
that's why it is time to remove the support fot these platforms.
Signed-off-by: Michal Simek
---
Documentation/devicetree/bindings/xilinx.txt | 143 --
Documentation/powerpc/bootwrapper.rst| 28 +-
MAINTAINERS | 6 -
arch/powerpc/Kconfig.debug | 2 +-
arch/powerpc/boot/Makefile | 7 +-
arch/powerpc/boot/dts/Makefile | 1 -
arch/powerpc/boot/dts/virtex440-ml507.dts| 406
arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
arch/powerpc/boot/ops.h | 1 -
arch/powerpc/boot/serial.c | 5 -
arch/powerpc/boot/uartlite.c | 79
arch/powerpc/boot/virtex.c | 97
arch/powerpc/boot/virtex405-head.S | 31 --
arch/powerpc/boot/wrapper| 8 -
arch/powerpc/configs/40x/virtex_defconfig| 75 ---
arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
arch/powerpc/configs/ppc40x_defconfig| 8 -
arch/powerpc/configs/ppc44x_defconfig| 8 -
arch/powerpc/include/asm/xilinx_intc.h | 16 -
arch/powerpc/include/asm/xilinx_pci.h| 21 -
arch/powerpc/kernel/cputable.c | 39 --
arch/powerpc/platforms/40x/Kconfig | 31 --
arch/powerpc/platforms/40x/Makefile | 1 -
arch/powerpc/platforms/40x/virtex.c | 54 ---
arch/powerpc/platforms/44x/Kconfig | 37 --
arch/powerpc/platforms/44x/Makefile | 2 -
arch/powerpc/platforms/44x/virtex.c | 60 ---
arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
arch/powerpc/platforms/Kconfig | 4 -
arch/powerpc/sysdev/Makefile | 2 -
arch/powerpc/sysdev/xilinx_intc.c| 88
arch/powerpc/sysdev/xilinx_pci.c | 132 --
arch/powerpc/xmon/ppc-dis.c | 6 -
arch/powerpc/xmon/ppc-opc.c | 23 -
arch/powerpc/xmon/ppc.h | 5 -
drivers/char/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
37 files changed, 7 insertions(+), 1993 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
delete mode 100644 arch/powerpc/boot/uartlite.c
delete mode 100644 arch/powerpc/boot/virtex.c
delete mode 100644 arch/powerpc/boot/virtex405-head.S
delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
delete mode 100644 arch/powerpc/platforms/40x/virtex.c
delete mode 100644 arch/powerpc/platforms/44x/virtex.c
delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/Documentation/devicetree/bindings/xilinx.txt
b/Documentation/devicetree/bindings/xilinx.txt
index d058ace29345..28199b31fe5e 100644
--- a/Documentation/devicetree/bindings/xilinx.txt
+++ b/Documentation/devicetree/bindings/xilinx.txt
@@ -86,149 +86,6 @@
xlnx,use-parity = <0>;
};
- Some IP cores actually implement 2 or more logical devices. In
- this case, the device should still describe the whole IP core with
- a single node and add a child node for each logical device. The
- ranges property can be used to translate from parent IP-core to the
- registers of each device. In addition, the parent node should be
- compatible with the bus type 'xlnx,compound', and should contain
- #address-cells and #size-cells, as with any other bus. (Note: this
- makes the assumption that both logical devices have the same bus
- binding. If this is not true, then separate nodes should be used
- for each logical device). The 'cell-index' property can be used to
- enumerate logical devices within an IP core. For example, the
- following is the system.mhs entry for the dual ps2 controller found
- on the ml403 reference design.
-
- BEGIN opb_ps2_dual_ref
- PARAMETER INSTANCE = opb_ps2_dual_ref_0
- PARAMETER HW_VER = 1.00.a
- PARAMETER C_BASEADDR = 0xA900
- PARAMETER C_HIGHADDR = 0xA9001FFF
- BUS_INTERFACE SOPB = opb_v20_0
- PORT Sys_Intr1 = ps2_1_intr
- PORT Sys_Intr2 = ps2_2
[PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi, recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform. U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed Based on current ppc/next. If anyone has any objection about it, please let me know. Thanks, Michal Michal Simek (2): sound: ac97: Remove sound driver for ancient platform powerpc: Remove Xilinx PPC405/PPC440 support Documentation/devicetree/bindings/xilinx.txt | 143 -- Documentation/powerpc/bootwrapper.rst| 28 +- MAINTAINERS |6 - arch/powerpc/Kconfig.debug |2 +- arch/powerpc/boot/Makefile |7 +- arch/powerpc/boot/dts/Makefile |1 - arch/powerpc/boot/dts/virtex440-ml507.dts| 406 -- arch/powerpc/boot/dts/virtex440-ml510.dts| 466 --- arch/powerpc/boot/ops.h |1 - arch/powerpc/boot/serial.c |5 - arch/powerpc/boot/uartlite.c | 79 -- arch/powerpc/boot/virtex.c | 97 -- arch/powerpc/boot/virtex405-head.S | 31 - arch/powerpc/boot/wrapper|8 - arch/powerpc/configs/40x/virtex_defconfig| 75 - arch/powerpc/configs/44x/virtex5_defconfig | 74 - arch/powerpc/configs/ppc40x_defconfig|8 - arch/powerpc/configs/ppc44x_defconfig|8 - arch/powerpc/include/asm/xilinx_intc.h | 16 - arch/powerpc/include/asm/xilinx_pci.h| 21 - arch/powerpc/kernel/cputable.c | 39 - arch/powerpc/platforms/40x/Kconfig | 31 - arch/powerpc/platforms/40x/Makefile |1 - arch/powerpc/platforms/40x/virtex.c | 54 - arch/powerpc/platforms/44x/Kconfig | 37 - arch/powerpc/platforms/44x/Makefile |2 - arch/powerpc/platforms/44x/virtex.c | 60 - arch/powerpc/platforms/44x/virtex_ml510.c| 30 - arch/powerpc/platforms/Kconfig |4 - arch/powerpc/sysdev/Makefile |2 - arch/powerpc/sysdev/xilinx_intc.c| 88 -- arch/powerpc/sysdev/xilinx_pci.c | 132 -- arch/powerpc/xmon/ppc-dis.c |6 - arch/powerpc/xmon/ppc-opc.c | 23 - arch/powerpc/xmon/ppc.h |5 - drivers/char/Kconfig |2 +- drivers/video/fbdev/Kconfig |2 +- sound/drivers/Kconfig| 12 - sound/drivers/Makefile |2 - sound/drivers/ml403-ac97cr.c | 1298 -- 40 files changed, 7 insertions(+), 3305 deletions(-) delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts delete mode 100644 arch/powerpc/boot/uartlite.c delete mode 100644 arch/powerpc/boot/virtex.c delete mode 100644 arch/powerpc/boot/virtex405-head.S delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h delete mode 100644 arch/powerpc/platforms/40x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c delete mode 100644 sound/drivers/ml403-ac97cr.c -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
On 19. 03. 20 2:08, Hyun Kwon wrote: > Hi Sam, > > On Wed, 2020-03-18 at 12:26:51 -0700, Sam Ravnborg wrote: >> On Wed, Mar 18, 2020 at 05:37:24PM +0200, Laurent Pinchart wrote: >>> From: Hyun Kwon >>> >>> The bindings describe the ZynqMP DP subsystem. They don't support the >>> interface with the programmable logic (FPGA) or audio yet. >>> >>> Signed-off-by: Hyun Kwon >>> Signed-off-by: Laurent Pinchart >>> Reviewed-by: Rob Herring >> >> Bikeshedding - examples with indent on 4 spaces to make them easier to >> read. >> >> Would it be possible to make this binding: (GPL-2.0-only OR BSD-2-Clause) >> This is preferred for new bindings. >> In this case asking Hyun Kwon should be enough? > > It should be possible. But to be safer and if needed, I need to check with > corperate policy before I can confirm. > > Michal, have you already checked about adding 'OR BSD-2-Clause'? or should I > take it up to Xilinx legal? I haven't had any discussion with Xilinx legal on this. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 4/4] arm64: dts: zynqmp: zcu106-revA: Wire up the DisplayPort subsystem
On 08. 11. 19 18:59, Laurent Pinchart wrote:
> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
> the DisplayPort connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> index 93ce7eb81498..4656f25b6b04 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> @@ -13,6 +13,7 @@
> #include "zynqmp-clk.dtsi"
> #include
> #include
> +#include
>
> / {
> model = "ZynqMP ZCU106 RevA";
> @@ -69,6 +70,17 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy-names = "dp-phy0", "dp-phy1";
> + phys = < PHY_TYPE_DP 0 3 2700>,
> +< PHY_TYPE_DP 1 3 2700>;
It is aligned with stuff in Xilinx tree.
I think that putting any clock value here is wrong.
It should really be pointing to whatever it is.
Then you can support more cases where clock doesn't need to be fixed and
it is also aligned with clock binding.
> +};
> +
> /* fpd_dma clk 667MHz, lpd_dma 500MHz */
> _dma_chan1 {
> status = "okay";
> @@ -503,6 +515,10 @@
> no-1-8-v;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
>
M
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/21] DT cpu node iterator
Hi Rob, 2018-09-05 21:37 GMT+02:00 Rob Herring : > This series adds an iterator for cpu nodes and converts users over to use > it or of_get_cpu_node in some cases. This allows us to remove the > dependency on device_type property for cpu nodes though removing that > from DTS files will have to wait for some time. In some cases, this makes > the DT search more strict by only looking in /cpus child nodes rather > than any node with the device_type == cpu. The iterator also honors the > status property which is often forgotten. > > I've only tested on ARM under QEMU and compiled powerpc. > Do you have this somewhere in your tree not to apply 21 patches by hand? Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver
On 11.1.2018 09:07, Daniel Vetter wrote: > On Thu, Jan 11, 2018 at 02:07:08AM +, Hyun Kwon wrote: >> Hi Daniel, >> >>> -Original Message- >>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel >>> Vetter >>> Sent: Tuesday, January 09, 2018 1:57 AM >>> To: Hyun Kwon <hy...@xilinx.com> >>> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal >>> Simek <michal.si...@xilinx.com> >>> Subject: Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM >>> KMS driver >>> >>> On Thu, Jan 04, 2018 at 06:05:49PM -0800, Hyun Kwon wrote: >>>> Hi, >>>> >>>> This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort >>>> subsystem. The Xilinx ZynqMP SoC has a hardened full display pipeline >>>> which supports blending of up to 2 planes, and the encoder is >>>> DisplayPort v1.2 compatible. >>>> >>>> This series mainly includes 2 sets: Xilinx DRM KMS (patch 1/10 - 5/10) >>>> and ZynqMP DP subsystem drivers (patch 6/10 - 10/10). >>>> >>>> The Xilinx DRM KMS is intended as a common layer shared across other >>>> (upcoming) Xilinx sub-drivers. It helps sub-drivers for both hardened as >>>> well as soft IPs interoperate together. >>>> >>>> ZynqMP DP subsystem driver is a sub-driver that implements >>> corresponding >>>> drm objects (crtc, plane, encoder, connector,,,) for ZynqMP SoC display >>>> pipeline. The entire pipeline is mainly partitioned into 2 blocks: >>>> generic display logic (zynqmp_disp.c) such as blending, csc,,, and the >>>> DP transmitter logic (zynqmp_dp.c). >>> >>> I read through it all (well mostly the drm relevant bits, not your backend >>> code) and looks fairly resonable. Few minor clenaups and code removals >>> tbh. >>> >>> Wrt merging/maintianing, do you want to maintain it as part of the >>> drm-misc small drivers group? Highly recommended imo. See >>> >>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm- >>> misc.html#small-drivers >>> >>> for details. Ideally we'd need 2 xilinx maintainers to be able to push >>> patches & cross-review stuff. >> >> I don't have any preference on how to maintain, so I'll follow your >> suggestion. One thing that may be worth a note is that there is sizable >> amount of development within Xilinx, and those will come in near future >> (considering what can be done with FPGA :-)). I'll look for the 2nd >> reviewer, and specify that in the next patch if found. > > If the xilinx activity gets too much we can always split things up again. > But if it's just the occasional burst (around a new product for example), > then drm-misc has ample of bandwidth to absorb that. > > And yes the idea is very much that all regular contributors would have > commit rights too. All to reduce friction and make it easier to > contribute. Right now I think it is visible that everything needs to be reviewed properly to make sure that we are doing these stuff properly. This topic can be refreshed in future but I don't think we are there yet. Thanks, Michal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
