* Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI
From: Adrian Hunter @ 2016-11-09 13:24 UTC (permalink / raw)
To: Zach Brown, ulf.hansson; +Cc: linux-mmc, linux-kernel
In-Reply-To: <1478635635-14953-3-git-send-email-zach.brown@ni.com>
On 08/11/16 22:07, Zach Brown wrote:
> On NI 9037 boards the max SDIO frequency is limited by trace lengths
> and other layout choices. The max SDIO frequency is stored in an ACPI
> table, as MXFQ.
>
> The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the
> f_max field of the host with it.
>
> Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
> Reviewed-by: Josh Cartwright <joshc@ni.com>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> ---
> drivers/mmc/host/sdhci-pci-core.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index c333ce2..4ac7f16 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -27,6 +27,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/mmc/slot-gpio.h>
> #include <linux/mmc/sdhci-pci-data.h>
> +#include <linux/acpi.h>
>
> #include "sdhci.h"
> #include "sdhci-pci.h"
> @@ -377,6 +378,35 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot *slot)
>
> static int ni_byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
> {
> +#ifdef CONFIG_ACPI
> + /* Get max freq from ACPI for NI hardware */
> + acpi_handle acpi_hdl;
> + acpi_status status;
> + struct acpi_buffer acpi_result = {
> + ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *acpi_buffer;
> + int max_freq;
> +
> + status = acpi_get_handle(ACPI_HANDLE(&slot->chip->pdev->dev), "MXFQ",
> + &acpi_hdl);
Is "MXFQ" an object that has already been deployed or are you inventing it
now? In the latter case, did you consider device properties as an alternative?
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + status = acpi_evaluate_object(acpi_hdl, NULL,
> + NULL, &acpi_result);
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> +
> + acpi_buffer = (union acpi_object *)acpi_result.pointer;
> +
> + if (acpi_buffer->type != ACPI_TYPE_INTEGER)
> + return -EINVAL;
> +
> + max_freq = acpi_buffer->integer.value;
> +
> + slot->host->mmc->f_max = max_freq * 1000000;
> +#endif
> +
> slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE;
> return 0;
> }
>
^ permalink raw reply
* [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Dan Carpenter @ 2016-11-09 13:28 UTC (permalink / raw)
To: tiffany.lin; +Cc: linux-media, linux-mediatek
Hello Tiffany Lin,
The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
520 static int vidioc_vdec_qbuf(struct file *file, void *priv,
521 struct v4l2_buffer *buf)
522 {
523 struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
524 struct vb2_queue *vq;
525 struct vb2_buffer *vb;
526 struct mtk_video_dec_buf *mtkbuf;
527 struct vb2_v4l2_buffer *vb2_v4l2;
528
529 if (ctx->state == MTK_STATE_ABORT) {
530 mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error",
531 ctx->id);
532 return -EIO;
533 }
534
535 vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
536 vb = vq->bufs[buf->index];
Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow. It seems simple
enough to analyse the call tree.
__video_do_ioctl()
-> v4l_qbuf()
-> vidioc_vdec_qbuf()
It seems like Smatch is correct. I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.
This has obvious security implications. Can someone take a look at
this?
537 vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
538 mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
539
540 if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
541 (buf->m.planes[0].bytesused == 0)) {
542 mtkbuf->lastframe = true;
543 mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, %d) vb=%p",
544 ctx->id, buf->type, buf->index,
545 mtkbuf->lastframe, buf->bytesused,
546 buf->m.planes[0].bytesused, buf->length,
547 vb);
548 }
549
550 return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
551 }
regards,
dan carpenter
^ permalink raw reply
* [PATCH V2 4/4] soc/tegra: pmc: Make configuration of IO pads in atomic context
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
The IO pad voltage configuration can be done in the regulator
notifier callback which is atomic in nature.
Replace the mutex with spin lock for the locking mechanism.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
New in series based on pinctrl driver requirement.
---
drivers/soc/tegra/pmc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 916a94b..52cd218 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -172,6 +172,7 @@ struct tegra_pmc_soc {
* @lp0_vec_size: size of the LP0 warm boot code
* @powergates_available: Bitmap of available power gates
* @powergates_lock: mutex for power gate register access
+ * @io_pad_lock: Spinlock for IO pad voltage register access
* @plat_subdevs: Platform device for PMC child devices.
*/
struct tegra_pmc {
@@ -199,6 +200,7 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);
struct mutex powergates_lock;
+ struct spinlock io_pad_lock;
struct platform_device **plat_subdevs;
};
@@ -1103,7 +1105,7 @@ int tegra_io_pad_set_voltage(enum tegra_io_pad id,
if (pad->voltage == UINT_MAX)
return -ENOTSUPP;
- mutex_lock(&pmc->powergates_lock);
+ spin_lock(&pmc->io_pad_lock);
/* write-enable PMC_PWR_DET_VALUE[pad->voltage] */
value = tegra_pmc_readl(PMC_PWR_DET);
@@ -1120,7 +1122,7 @@ int tegra_io_pad_set_voltage(enum tegra_io_pad id,
tegra_pmc_writel(value, PMC_PWR_DET_VALUE);
- mutex_unlock(&pmc->powergates_lock);
+ spin_unlock(&pmc->io_pad_lock);
usleep_range(100, 250);
@@ -1800,6 +1802,7 @@ static int __init tegra_pmc_early_init(void)
u32 value;
mutex_init(&pmc->powergates_lock);
+ spin_lock_init(&pmc->io_pad_lock);
np = of_find_matching_node_and_match(NULL, tegra_pmc_match, &match);
if (!np) {
--
2.1.4
^ permalink raw reply related
* [PATCH V2 1/4] soc/tegra: pmc: Remove legacy Tegra I/O rail API
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Remove tegra_io_rail_power_on() and tegra_io_rail_power_off()
from header as client has been moved to new APIs.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
include/soc/tegra/pmc.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 52780a77..9c314a6 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -203,16 +203,6 @@ static inline int tegra_io_pad_get_voltage(enum tegra_io_pad id)
{
return -ENOSYS;
}
-
-static inline int tegra_io_rail_power_on(unsigned int id)
-{
- return -ENOSYS;
-}
-
-static inline int tegra_io_rail_power_off(unsigned int id)
-{
- return -ENOSYS;
-}
#endif /* CONFIG_ARCH_TEGRA */
#endif /* __SOC_TEGRA_PMC_H__ */
--
2.1.4
^ permalink raw reply related
* [PATCH V2 2/4] soc/tegra: pmc: Add interface to get IO pad power status
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Add API to get the IO pad power status of the Tegra IO pads.
This will help client driver to get the current power status
of IO pads for handling IO pad power.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
drivers/soc/tegra/pmc.c | 22 ++++++++++++++++++++++
include/soc/tegra/pmc.h | 6 ++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb3715f..44546bd 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1063,6 +1063,28 @@ int tegra_io_pad_power_disable(enum tegra_io_pad id)
}
EXPORT_SYMBOL(tegra_io_pad_power_disable);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ const struct tegra_io_pad_soc *pad;
+ unsigned long status;
+ u32 value;
+ int bit;
+
+ pad = tegra_io_pad_find(pmc, id);
+ if (!pad)
+ return -ENOENT;
+
+ if (pad->dpd == UINT_MAX)
+ return -ENOTSUPP;
+
+ status = (pad->dpd < 32) ? IO_DPD_STATUS : IO_DPD2_STATUS;
+ bit = pad->dpd % 32;
+ value = tegra_pmc_readl(status);
+
+ return !!(value & BIT(bit));
+}
+EXPORT_SYMBOL(tegra_io_pad_power_get_status);
+
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 9c314a6..18cf172 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -152,6 +152,7 @@ int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
int tegra_io_pad_power_enable(enum tegra_io_pad id);
int tegra_io_pad_power_disable(enum tegra_io_pad id);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id);
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage);
int tegra_io_pad_get_voltage(enum tegra_io_pad id);
@@ -193,6 +194,11 @@ static inline int tegra_io_pad_power_disable(enum tegra_io_pad id)
return -ENOSYS;
}
+static inline int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ return -ENOSYS;
+}
+
static inline int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
--
2.1.4
^ permalink raw reply related
* [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Dan Carpenter @ 2016-11-09 13:28 UTC (permalink / raw)
To: tiffany.lin-NuS5LvNUpcJWk0Htik3J/w
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
Hello Tiffany Lin,
The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
520 static int vidioc_vdec_qbuf(struct file *file, void *priv,
521 struct v4l2_buffer *buf)
522 {
523 struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
524 struct vb2_queue *vq;
525 struct vb2_buffer *vb;
526 struct mtk_video_dec_buf *mtkbuf;
527 struct vb2_v4l2_buffer *vb2_v4l2;
528
529 if (ctx->state == MTK_STATE_ABORT) {
530 mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error",
531 ctx->id);
532 return -EIO;
533 }
534
535 vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
536 vb = vq->bufs[buf->index];
Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow. It seems simple
enough to analyse the call tree.
__video_do_ioctl()
-> v4l_qbuf()
-> vidioc_vdec_qbuf()
It seems like Smatch is correct. I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.
This has obvious security implications. Can someone take a look at
this?
537 vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
538 mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
539
540 if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
541 (buf->m.planes[0].bytesused == 0)) {
542 mtkbuf->lastframe = true;
543 mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, %d) vb=%p",
544 ctx->id, buf->type, buf->index,
545 mtkbuf->lastframe, buf->bytesused,
546 buf->m.planes[0].bytesused, buf->length,
547 vb);
548 }
549
550 return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
551 }
regards,
dan carpenter
^ permalink raw reply
* [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Cao jin @ 2016-11-09 13:28 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <CAKgT0UeaoGfOOC1=h4pGk+=FDd5EqvgRGAdk1StLuiW1-M8tVA@mail.gmail.com>
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
> On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
>> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>>>> On Nov 8 15:06, Cao jin wrote:
>>>>> When running as guest, under certain condition, it will oops as following.
>>>>> writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>>>>> is NULL. While other register access won't oops kernel because they use
>>>>> wr32/rd32 which have a defense against NULL pointer.
>>>>> [...]
>>>>
>>>> Incidentally we're just looking for a solution to that problem too.
>>>> Do three patches to fix the same problem at rougly the same time already
>>>> qualify as freak accident?
>>>>
>>>> FTR, I attached my current patch, which I was planning to submit after
>>>> some external testing.
>>>>
>>>> However, all three patches have one thing in common: They workaround
>>>> a somewhat dubious resetting of the hardware address to NULL in case
>>>> reading from a register failed.
>>>>
>>>> That makes me wonder if setting the hardware address to NULL in
>>>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>>>> which return value is *never* tested for validity in the calling
>>>> functions and leads to subsequent crashes since no tests for hw_addr ==
>>>> NULL are performed.
>>>>
>>>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>>>> graceful way to handle the "surprise removal"?
>>>
>>> Answering this from my home account because, well, work is Outlook.
>>>
>>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>>> uncertain that the surprise removal code actually works the way I
>>> thought previously and I think I took a lot of it out of my local code.
>>>
>>> Unfortuantely I don't have any equipment that I can use to reproduce
>>> surprise removal any longer so that means I wouldn't be able to test
>>> anything. I have to defer to you or Cao Jin.
>>
>> I'm not too keen to rip out a PCIe NIC under power from my locale
>> desktop machine, but I think an actual surprise removal is not the
>> problem.
>>
>> As described in my git log entry, the error condition in igb_rd32 can be
>> triggered during a suspend. The HW has been put into a sleep state but
>> some register read requests are apparently not guarded against that
>> situation. Reading a register in this state returns -1, thus a suspend
>> is erroneously triggering the "surprise removal" sequence.
>
> The question I would have is what is reading the device when it is in
> this state. The watchdog and any other functions that would read the
> device should be disabled.
>
> One possibility could be a race between a call to igb_close and the
> igb_suspend function. We have seen some of those pop up recently on
> ixgbe and it looks like igb has the same bug. We should probably be
> using the rtnl_lock to guarantee that netif_device_detach and the call
> to __igb_close are completed before igb_close could possibly be called
> by the network stack.
>
>> Here's a raw idea:
>>
>> - Note that device is suspended in e1000_hw struct. Don't trigger
>> error sequence in igb_rd32 if so (...and return a 0 value???)
>
> The thing is that a suspended device should not be accessed at all.
> If we are accessing it while it is suspended then that is a bug. If
> you could throw a WARN_ON call in igb_rd32 to capture where this is
> being triggered that might be useful.
>
>> - Otherwise assume it's actually a surprise removal. In theory that
>> should somehow trigger a device removal sequence, kind of like
>> calling igb_remove, no?
>
> Well a read of the MMIO region while suspended is more of a surprise
> read since there shouldn't be anything going on. We need to isolate
> where that read is coming from and fix it.
>
> Thanks.
>
> - Alex
>
>
> .
>
^ permalink raw reply
* [Buildroot] [PATCH 1/1] olimex_a20_olinuxino_lime2: dump U-Boot to 2016.05
From: Jan Viktorin @ 2016-11-09 13:27 UTC (permalink / raw)
To: buildroot
The patch fixes build by GCC 5 (unsupported by the older U-Boot).
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
configs/olimex_a20_olinuxino_lime2_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/olimex_a20_olinuxino_lime2_defconfig b/configs/olimex_a20_olinuxino_lime2_defconfig
index 57dda72..87fc674 100644
--- a/configs/olimex_a20_olinuxino_lime2_defconfig
+++ b/configs/olimex_a20_olinuxino_lime2_defconfig
@@ -25,7 +25,7 @@ BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="A20-OLinuXino-Lime2"
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2015.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.05"
BR2_TARGET_UBOOT_SPL=y
BR2_TARGET_UBOOT_SPL_NAME="u-boot-sunxi-with-spl.bin"
BR2_PACKAGE_HOST_GENIMAGE=y
--
2.9.3
^ permalink raw reply related
* [PATCH] serial: 8250_pxa: hide early console setup when disabled
From: Arnd Bergmann @ 2016-11-09 13:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Jiri Slaby, Robert Jarzmik, linux-serial,
linux-kernel
The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:
drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'
This adds an #ifdef like the other glue drivers have it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/tty/serial/8250/8250_pxa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pxa.c b/drivers/tty/serial/8250/8250_pxa.c
index 31f27d95d8b4..4d68731af534 100644
--- a/drivers/tty/serial/8250/8250_pxa.c
+++ b/drivers/tty/serial/8250/8250_pxa.c
@@ -170,6 +170,7 @@ static struct platform_driver serial_pxa_driver = {
module_platform_driver(serial_pxa_driver);
+#ifdef CONFIG_SERIAL_8250_CONSOLE
static int __init early_serial_pxa_setup(struct earlycon_device *device,
const char *options)
{
@@ -182,6 +183,7 @@ static int __init early_serial_pxa_setup(struct earlycon_device *device,
return early_serial8250_setup(device, NULL);
}
OF_EARLYCON_DECLARE(early_pxa, "mrvl,pxa-uart", early_serial_pxa_setup);
+#endif
MODULE_AUTHOR("Sergei Ianovich");
MODULE_LICENSE("GPL");
--
2.9.0
^ permalink raw reply related
* [PATCH v2] MIPS: mm: Fix output of __do_page_fault
From: Matt Redfearn @ 2016-11-09 13:26 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, Matt Redfearn, Paul Gortmaker, linux-kernel,
Kirill A. Shutemov, Andrew Morton
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __do_page_fault on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont
to provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---
arch/mips/mm/fault.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index d56a855828c2..3bef306cdfdb 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -209,17 +209,18 @@ static void __kprobes __do_page_fault(struct pt_regs *regs, unsigned long write,
if (show_unhandled_signals &&
unhandled_signal(tsk, SIGSEGV) &&
__ratelimit(&ratelimit_state)) {
- pr_info("\ndo_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx",
+ pr_info("do_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx\n",
tsk->comm,
write ? "write access to" : "read access from",
field, address);
pr_info("epc = %0*lx in", field,
(unsigned long) regs->cp0_epc);
- print_vma_addr(" ", regs->cp0_epc);
+ print_vma_addr(KERN_CONT " ", regs->cp0_epc);
+ pr_cont("\n");
pr_info("ra = %0*lx in", field,
(unsigned long) regs->regs[31]);
- print_vma_addr(" ", regs->regs[31]);
- pr_info("\n");
+ print_vma_addr(KERN_CONT " ", regs->regs[31]);
+ pr_cont("\n");
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] MIPS: mm: Fix output of __do_page_fault
From: Matt Redfearn @ 2016-11-09 13:26 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, Matt Redfearn, Paul Gortmaker, linux-kernel,
Kirill A. Shutemov, Andrew Morton
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __do_page_fault on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont
to provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---
arch/mips/mm/fault.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index d56a855828c2..3bef306cdfdb 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -209,17 +209,18 @@ static void __kprobes __do_page_fault(struct pt_regs *regs, unsigned long write,
if (show_unhandled_signals &&
unhandled_signal(tsk, SIGSEGV) &&
__ratelimit(&ratelimit_state)) {
- pr_info("\ndo_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx",
+ pr_info("do_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx\n",
tsk->comm,
write ? "write access to" : "read access from",
field, address);
pr_info("epc = %0*lx in", field,
(unsigned long) regs->cp0_epc);
- print_vma_addr(" ", regs->cp0_epc);
+ print_vma_addr(KERN_CONT " ", regs->cp0_epc);
+ pr_cont("\n");
pr_info("ra = %0*lx in", field,
(unsigned long) regs->regs[31]);
- print_vma_addr(" ", regs->regs[31]);
- pr_info("\n");
+ print_vma_addr(KERN_CONT " ", regs->regs[31]);
+ pr_cont("\n");
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
--
2.7.4
^ permalink raw reply related
* Re: krogoth 2.1.2 status
From: Joshua Lock @ 2016-11-09 13:26 UTC (permalink / raw)
To: Richard Purdie, openembedded-core, Armin Kuster
In-Reply-To: <1478694607.23123.176.camel@linuxfoundation.org>
On Wed, 2016-11-09 at 12:30 +0000, Richard Purdie wrote:
> I ran a krogoth 2.1.2 build. It did have some issues:
>
> * one runtime sanity test had a timeout issue
> * some urls are stale (perpetual problem)
> * musl runtime testing fails (never tested on krogoth previously)
> * no-x11 runtime testing had a failure (never tested on krogoth
> previously)
We can update the autobuilder not to run these tests for krogoth.
I've filed a bug for musl:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10634
for no-x11 there's a single failure, it might be worthwhile backporting
fixes to make that work?
Regards,
Joshua
^ permalink raw reply
* Re: [PATCH v3][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT
From: Michael Kerrisk (man-pages) @ 2016-11-09 13:26 UTC (permalink / raw)
To: Wang Nan, vincent.weaver
Cc: mtk.manpages, pi3orama, linux-kernel, lizefan, linux-man
In-Reply-To: <20161024065256.160703-2-wangnan0@huawei.com>
Hello Wang Nan,
On 10/24/2016 08:52 AM, Wang Nan wrote:
> Linux 4.7 (86e7972f690c1017fd086cdfe53d8524e68c661c) introduces
> PERF_EVENT_IOC_PAUSE_OUTPUT feature. Document it.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Reviewed-by: Vince Weaver <vincent.weaver@maine.edu>
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> ---
> man2/perf_event_open.2 | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index fade28c..561331c 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -1687,6 +1687,15 @@ the
> .I data_tail
> value should be written by user space to reflect the last read data.
> In this case, the kernel will not overwrite unread data.
> +
> +When the mapping is read only (without
> +.BR PROT_WRITE ),
> +setting .I data_tail is not allowed.
Missing line breaks in the preceding line.
> +In this case, the kernel will overwrite data when sample coming, unless
I find that last line hard to understand.
s/sample coming/a sample arrives/?
> +the ring buffer is paused by a
> +.BR PERF_EVENT_IOC_PAUSE_OUTPUT
> +.BR ioctl (2)
> +system call before reading.
> .TP
> .IR data_offset " (since Linux 4.1)"
> .\" commit e8c6deac69629c0cb97c3d3272f8631ef17f8f0f
> @@ -2865,6 +2874,21 @@ The argument is a BPF program file descriptor that was created by
> a previous
> .BR bpf (2)
> system call.
> +.TP
> +.BR PERF_EVENT_IOC_PAUSE_OUTPUT " (since Linux 4.7)"
> +.\" commit 86e7972f690c1017fd086cdfe53d8524e68c661c
> +This allows pausing and resuming the event's ring-buffer. A
> +paused ring-buffer does not prevent generation of samples, but simply
> +discards the samples. The discarded samples are considered lost,
> +causing
> +.BR PERF_RECORD_LOST
> +to be generated when possible.
> +
> +The argument is an integer. A nonzero value pauses the ring-buffer,
> +zero resumes the ring-buffer.
> +
> +Pausing a read only ring buffer before reading from it without having
> +to worry about data being overwritten.
That last sentence seems incomplete. I can't understand what you
mean here?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* [PATCH V2 3/4] soc/tegra: pmc: Register PMC child devices as platform device
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Power Management Controller(PMC) of Tegra does the multiple chip
power management related functionality for internal and IO interfacing.
Some of the functionalities are power gating of IP blocks, IO pads
voltage and power state configuration, system power state configurations,
wakeup controls etc.
Different functionalities of the PMC are provided through different
framework like IO pads control can be provided through pinctrl framework,
IO power control is via misc driver etc. All sub functionalities are
represented as PMC child devices.
Register the PMC child devices as platform device and fill the child
devices table for Tegra124 and Tegra210.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
drivers/soc/tegra/pmc.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 44546bd..916a94b 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -145,6 +145,9 @@ struct tegra_pmc_soc {
const struct tegra_io_pad_soc *io_pads;
unsigned int num_io_pads;
+
+ const char **sub_devs_name;
+ unsigned int num_sub_devs;
};
/**
@@ -169,6 +172,7 @@ struct tegra_pmc_soc {
* @lp0_vec_size: size of the LP0 warm boot code
* @powergates_available: Bitmap of available power gates
* @powergates_lock: mutex for power gate register access
+ * @plat_subdevs: Platform device for PMC child devices.
*/
struct tegra_pmc {
struct device *dev;
@@ -195,6 +199,7 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);
struct mutex powergates_lock;
+ struct platform_device **plat_subdevs;
};
static struct tegra_pmc *pmc = &(struct tegra_pmc) {
@@ -1375,6 +1380,43 @@ static void tegra_pmc_init_tsense_reset(struct tegra_pmc *pmc)
of_node_put(np);
}
+static int tegra_pmc_init_sub_devs(struct tegra_pmc *pmc)
+{
+ int ret, i;
+
+ if (!pmc->soc->num_sub_devs)
+ return 0;
+
+ pmc->plat_subdevs = devm_kzalloc(pmc->dev, pmc->soc->num_sub_devs *
+ sizeof(**pmc->plat_subdevs),
+ GFP_KERNEL);
+ if (!pmc->plat_subdevs)
+ return -ENOMEM;
+
+ for (i = 0; i < pmc->soc->num_sub_devs; ++i) {
+ pmc->plat_subdevs[i] = platform_device_register_data(pmc->dev,
+ pmc->soc->sub_devs_name[i],
+ 0, NULL, 0);
+ if (IS_ERR(pmc->plat_subdevs[i])) {
+ ret = PTR_ERR(pmc->plat_subdevs[i]);
+ dev_err(pmc->dev,
+ "Failed to register platform device for %s: %d\n",
+ pmc->soc->sub_devs_name[i], ret);
+ goto pdev_cleanups;
+ }
+ }
+
+ return 0;
+
+pdev_cleanups:
+ while (--i >= 0) {
+ platform_device_unregister(pmc->plat_subdevs[i]);
+ pmc->plat_subdevs[i] = NULL;
+ }
+
+ return ret;
+}
+
static int tegra_pmc_probe(struct platform_device *pdev)
{
void __iomem *base;
@@ -1426,6 +1468,11 @@ static int tegra_pmc_probe(struct platform_device *pdev)
return err;
}
+ err = tegra_pmc_init_sub_devs(pmc);
+ if (err < 0)
+ dev_warn(pmc->dev, "Failed to register PMC sub devices: %d\n",
+ err);
+
mutex_lock(&pmc->powergates_lock);
iounmap(pmc->base);
pmc->base = base;
@@ -1608,6 +1655,10 @@ static const struct tegra_io_pad_soc tegra124_io_pads[] = {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra124_sub_devs_name[] = {
+ "pinctrl-t124-io-pad",
+};
+
static const struct tegra_pmc_soc tegra124_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra124_powergates),
.powergates = tegra124_powergates,
@@ -1617,6 +1668,8 @@ static const struct tegra_pmc_soc tegra124_pmc_soc = {
.has_gpu_clamps = true,
.num_io_pads = ARRAY_SIZE(tegra124_io_pads),
.io_pads = tegra124_io_pads,
+ .sub_devs_name = tegra124_sub_devs_name,
+ .num_sub_devs = ARRAY_SIZE(tegra124_sub_devs_name),
};
static const char * const tegra210_powergates[] = {
@@ -1694,6 +1747,10 @@ static const struct tegra_io_pad_soc tegra210_io_pads[] = {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra210_sub_devs_name[] = {
+ "pinctrl-t210-io-pad",
+};
+
static const struct tegra_pmc_soc tegra210_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra210_powergates),
.powergates = tegra210_powergates,
@@ -1703,6 +1760,8 @@ static const struct tegra_pmc_soc tegra210_pmc_soc = {
.has_gpu_clamps = true,
.num_io_pads = ARRAY_SIZE(tegra210_io_pads),
.io_pads = tegra210_io_pads,
+ .sub_devs_name = tegra210_sub_devs_name,
+ .num_sub_devs = ARRAY_SIZE(tegra210_sub_devs_name),
};
static const struct of_device_id tegra_pmc_match[] = {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: sound: document axentia,tse850-pcm5142 bindings
From: Mark Brown @ 2016-11-09 13:25 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree
In-Reply-To: <1478622057-12426-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote:
> The TSE-850 is an FM Transmitter Station Equipment, designed to generate
> baseband signals for FM, mainly the DARC subcarrier, but other signals
> are also possible.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH V2 0/4] soc/tegra: pmc: Add support for IO pad configuration and sub-driver
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
Tegra SoC support the configutaion of IO pads to multi-level voltage
and low power state. The conifguration is done via pictrl framework
and the io pad driver in pinctrl frameowrk uses the APIs from pmc to
access PMC registers.
his series add the API to get the IO pad power status and register
the pmc child devices like IO pad drvier.
The patches were send earlier part of different series but applied
partially in the Thierry's t186 branch
https://github.com/thierryreding/linux/tree/tegra186.
Resending the patches as the new start to avoid any confusion.
This need to be applied in
https://github.com/thierryreding/linux/tree/tegra186
---
Changes from V1:
- make the IO pad votlage configurations to the atomic context as 4th patch of
series.
Laxman Dewangan (4):
soc/tegra: pmc: Remove legacy Tegra I/O rail API
soc/tegra: pmc: Add interface to get IO pad power status
soc/tegra: pmc: Register PMC child devices as platform device
soc/tegra: pmc: Make configuration of IO pads in atomic context
drivers/soc/tegra/pmc.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++--
include/soc/tegra/pmc.h | 14 +++-----
2 files changed, 91 insertions(+), 11 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Cao jin @ 2016-11-09 13:28 UTC (permalink / raw)
To: Alexander Duyck, Hisashi T Fujinaka, Netdev, intel-wired-lan,
linux-kernel@vger.kernel.org, Izumi, Taku/泉 拓,
vinschen
In-Reply-To: <CAKgT0UeaoGfOOC1=h4pGk+=FDd5EqvgRGAdk1StLuiW1-M8tVA@mail.gmail.com>
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
> On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
>> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>>>> On Nov 8 15:06, Cao jin wrote:
>>>>> When running as guest, under certain condition, it will oops as following.
>>>>> writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>>>>> is NULL. While other register access won't oops kernel because they use
>>>>> wr32/rd32 which have a defense against NULL pointer.
>>>>> [...]
>>>>
>>>> Incidentally we're just looking for a solution to that problem too.
>>>> Do three patches to fix the same problem at rougly the same time already
>>>> qualify as freak accident?
>>>>
>>>> FTR, I attached my current patch, which I was planning to submit after
>>>> some external testing.
>>>>
>>>> However, all three patches have one thing in common: They workaround
>>>> a somewhat dubious resetting of the hardware address to NULL in case
>>>> reading from a register failed.
>>>>
>>>> That makes me wonder if setting the hardware address to NULL in
>>>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>>>> which return value is *never* tested for validity in the calling
>>>> functions and leads to subsequent crashes since no tests for hw_addr ==
>>>> NULL are performed.
>>>>
>>>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>>>> graceful way to handle the "surprise removal"?
>>>
>>> Answering this from my home account because, well, work is Outlook.
>>>
>>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>>> uncertain that the surprise removal code actually works the way I
>>> thought previously and I think I took a lot of it out of my local code.
>>>
>>> Unfortuantely I don't have any equipment that I can use to reproduce
>>> surprise removal any longer so that means I wouldn't be able to test
>>> anything. I have to defer to you or Cao Jin.
>>
>> I'm not too keen to rip out a PCIe NIC under power from my locale
>> desktop machine, but I think an actual surprise removal is not the
>> problem.
>>
>> As described in my git log entry, the error condition in igb_rd32 can be
>> triggered during a suspend. The HW has been put into a sleep state but
>> some register read requests are apparently not guarded against that
>> situation. Reading a register in this state returns -1, thus a suspend
>> is erroneously triggering the "surprise removal" sequence.
>
> The question I would have is what is reading the device when it is in
> this state. The watchdog and any other functions that would read the
> device should be disabled.
>
> One possibility could be a race between a call to igb_close and the
> igb_suspend function. We have seen some of those pop up recently on
> ixgbe and it looks like igb has the same bug. We should probably be
> using the rtnl_lock to guarantee that netif_device_detach and the call
> to __igb_close are completed before igb_close could possibly be called
> by the network stack.
>
>> Here's a raw idea:
>>
>> - Note that device is suspended in e1000_hw struct. Don't trigger
>> error sequence in igb_rd32 if so (...and return a 0 value???)
>
> The thing is that a suspended device should not be accessed at all.
> If we are accessing it while it is suspended then that is a bug. If
> you could throw a WARN_ON call in igb_rd32 to capture where this is
> being triggered that might be useful.
>
>> - Otherwise assume it's actually a surprise removal. In theory that
>> should somehow trigger a device removal sequence, kind of like
>> calling igb_remove, no?
>
> Well a read of the MMIO region while suspended is more of a surprise
> read since there shouldn't be anything going on. We need to isolate
> where that read is coming from and fix it.
>
> Thanks.
>
> - Alex
>
>
> .
>
^ permalink raw reply
* Is Documentation/networking/phy.txt still up-to-date?
From: Sebastian Frias @ 2016-11-09 13:24 UTC (permalink / raw)
To: afleming, jgarzik, Måns Rullgård, Florian Fainelli
Cc: netdev, LKML, David S. Miller
Hi,
Documentation/networking/phy.txt discusses phy_connect and states that:
"...
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phydev->supported and phydev->advertising have any
values pruned from them which don't make sense for your controller (a 10/100
controller may be connected to a gigabit capable PHY, so you would need to
mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
for these bitfields. Note that you should not SET any bits, or the PHY may
get put into an unsupported state.
..."
However, 'drivers/net/ethernet/aurora/nb8800.c' for example, does SETs some
bits (in function 'nb8800_pause_adv').
I checked 'drivers/net/ethernet/broadcom/genet/bcmmii.c' and that one CLEARs
bits (as per the documentation).
Does anybody knows what is the correct/recommended approach?
Best regards,
Sebastian
^ permalink raw reply
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Mark Yao, Yakir Yang, Caesar Wang,
Douglas Anderson, David Wu, Jianqun Xu, devicetree, Brian Norris,
linux-kernel, zhangqing, linux-rockchip, Rob Herring, Will Deacon,
Ziyuan Xu, Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Mark Yao <mark.yao@rock-chips.com>
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 ++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e5b5b3d..f1d289a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1290,6 +1290,64 @@
status = "disabled";
};
+ vopl: vop@ff8f0000 {
+ compatible = "rockchip,rk3399-vop-lit";
+ reg = <0x0 0xff8f0000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopl_mmu>;
+ status = "disabled";
+
+ vopl_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopl_mmu: iommu@ff8f3f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff8f3f00 0x0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopl_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ vopb: vop@ff900000 {
+ compatible = "rockchip,rk3399-vop-big";
+ reg = <0x0 0xff900000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ status = "disabled";
+
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopb_mmu: iommu@ff903f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff903f00 0x0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopb_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu, Eric Auger
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Marc Zyngier,
Rafael J. Wysocki, Hanjun Guo, Jon Masters, Sinan Kaya,
Nate Watterson, Prem Mallappa, Dennis Chen, linux-acpi, linux-pci,
linux-kernel, linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: Lorenzo Pieralisi,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Eric Auger
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marc Zyngier,
Rafael J. Wysocki, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Jon Masters, Dennis Chen,
Prem Mallappa
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Brian Norris, Caesar Wang, Douglas Anderson,
David Wu, Jianqun Xu, devicetree, linux-kernel, zhangqing,
Shawn Lin, Rob Herring, Will Deacon, linux-rockchip, Mark Rutland,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Brian Norris <briannorris@chromium.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 09ebf4e..3659c56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -353,6 +353,60 @@
status = "disabled";
};
+ usbdrd3_0: usb@fe800000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3@fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "otg";
+ phys = <&tcphy0_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb@fe900000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3@fe900000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe900000 0x0 0x100000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "host";
+ phys = <&tcphy1_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller@fee00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-09 13:06 UTC (permalink / raw)
To: linus.walleij, robh+dt, mark.rutland, swarren, thierry.reding
Cc: gnurou, yamada.masahiro, jonathanh, linux-gpio, devicetree,
linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696782-11657-1-git-send-email-ldewangan@nvidia.com>
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
sources. When IO interfaces are not used then IO pads can be
configure in low power state to reduce the power consumption from
that IO pads.
On Tegra124, the voltage level of IO power rail source is auto
detected by hardware(SoC) and hence it is only require to configure
in low power mode if IO pads are not used.
On T210 onwards, the auto-detection of voltage level from IO power
rail is removed from SoC and hence SW need to configure the PMC
register explicitly to set proper voltage in IO pads based on
IO rail power source voltage.
This driver adds the IO pad driver to configure the power state and
IO pad voltage based on the usage and power tree via pincontrol
framework. The configuration can be static and dynamic.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
- Dropped the custom properties to set pad voltage and use regulator.
- Added support for regulator to get vottage in boot and configure IO
pad voltage.
- Add support for callback to handle regulator notification and configure
IO pad voltage based on voltage change.
---
drivers/pinctrl/tegra/Kconfig | 12 +
drivers/pinctrl/tegra/Makefile | 1 +
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 488 +++++++++++++++++++++++++++
3 files changed, 501 insertions(+)
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
diff --git a/drivers/pinctrl/tegra/Kconfig b/drivers/pinctrl/tegra/Kconfig
index 24e20cc..6004e5c 100644
--- a/drivers/pinctrl/tegra/Kconfig
+++ b/drivers/pinctrl/tegra/Kconfig
@@ -23,6 +23,18 @@ config PINCTRL_TEGRA210
bool
select PINCTRL_TEGRA
+config PINCTRL_TEGRA_IO_PAD
+ bool "Tegra IO pad Control Driver"
+ depends on ARCH_TEGRA && REGULATOR
+ select PINCONF
+ select PINMUX
+ help
+ NVIDIA Tegra124/210 SoC has IO pads which supports multi-voltage
+ level of interfacing and deep power down mode of IO pads. The
+ voltage of IO pads are SW configurable based on IO rail of that
+ pads on T210. This driver provides the interface to change IO pad
+ voltage and power state via pincontrol interface.
+
config PINCTRL_TEGRA_XUSB
def_bool y if ARCH_TEGRA
select GENERIC_PHY
diff --git a/drivers/pinctrl/tegra/Makefile b/drivers/pinctrl/tegra/Makefile
index d9ea2be..3ebaaa2 100644
--- a/drivers/pinctrl/tegra/Makefile
+++ b/drivers/pinctrl/tegra/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA210) += pinctrl-tegra210.o
+obj-$(CONFIG_PINCTRL_TEGRA_IO_PAD) += pinctrl-tegra-io-pad.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
new file mode 100644
index 0000000..f5cf0d0
--- /dev/null
+++ b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
@@ -0,0 +1,488 @@
+/*
+ * pinctrl-tegra-io-pad: IO PAD driver for configuration of IO rail and deep
+ * Power Down mode via pinctrl framework.
+ *
+ * Copyright (C) 2016 NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author: Laxman Dewangan <ldewangan@nvidia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <soc/tegra/pmc.h>
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinctrl-utils.h"
+
+/**
+ * Macro for 1.8V, keep 200mV as tolerance for deciding that
+ * IO pads should be set for 3.3V (high voltage) or 1.8V.
+ */
+#define TEGRA_IO_PAD_1800000UV_UPPER_LIMIT 2000000
+
+struct tegra_io_pads_cfg_info {
+ const char *name;
+ const unsigned int pins[1];
+ const char *vsupply;
+ enum tegra_io_pad pad_id;
+ bool support_low_power_state;
+};
+
+struct tegra_io_pad_soc_data {
+ const struct tegra_io_pads_cfg_info *pads_cfg;
+ int num_pads_cfg;
+ const struct pinctrl_pin_desc *pins_desc;
+ int num_pins_desc;
+};
+
+struct tegra_io_pads_regulator_info {
+ struct device *dev;
+ const struct tegra_io_pads_cfg_info *pads_cfg;
+ struct regulator *regulator;
+ struct notifier_block regulator_nb;
+};
+
+struct tegra_io_pads_info {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ struct tegra_io_pads_regulator_info *rinfo;
+ const struct tegra_io_pad_soc_data *soc_data;
+};
+
+static int tegra_iop_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ return tiopi->soc_data->num_pads_cfg;
+}
+
+static const char *tegra_iop_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
+ unsigned int group)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ return tiopi->soc_data->pads_cfg[group].name;
+}
+
+static int tegra_iop_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
+ unsigned int group,
+ const unsigned int **pins,
+ unsigned int *num_pins)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ *pins = tiopi->soc_data->pads_cfg[group].pins;
+ *num_pins = 1;
+
+ return 0;
+}
+
+static const struct pinctrl_ops tegra_iop_pinctrl_ops = {
+ .get_groups_count = tegra_iop_pinctrl_get_groups_count,
+ .get_group_name = tegra_iop_pinctrl_get_group_name,
+ .get_group_pins = tegra_iop_pinctrl_get_group_pins,
+ .dt_node_to_map = pinconf_generic_dt_node_to_map_pin,
+ .dt_free_map = pinctrl_utils_free_map,
+};
+
+static int tegra_io_pad_pinconf_get(struct pinctrl_dev *pctldev,
+ unsigned int pin, unsigned long *config)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+ int param = pinconf_to_config_param(*config);
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &tiopi->soc_data->pads_cfg[pin];
+ enum tegra_io_pad pad_id = pads_cfg->pad_id;
+ int arg = 0;
+ int ret;
+
+ switch (param) {
+ case PIN_CONFIG_LOW_POWER_MODE:
+ ret = tegra_io_pad_power_get_status(pad_id);
+ if (ret < 0)
+ return ret;
+ arg = !ret;
+ break;
+
+ default:
+ dev_err(tiopi->dev, "The parameter %d not supported\n", param);
+ return -EINVAL;
+ }
+
+ *config = pinconf_to_config_packed(param, (u16)arg);
+ return 0;
+}
+
+static int tegra_io_pad_pinconf_set(struct pinctrl_dev *pctldev,
+ unsigned int pin, unsigned long *configs,
+ unsigned int num_configs)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &tiopi->soc_data->pads_cfg[pin];
+ int pad_id = pads_cfg->pad_id;
+ u16 param_val;
+ int param;
+ int ret;
+ int i;
+
+ for (i = 0; i < num_configs; i++) {
+ param = pinconf_to_config_param(configs[i]);
+ param_val = pinconf_to_config_argument(configs[i]);
+
+ switch (param) {
+ case PIN_CONFIG_LOW_POWER_MODE:
+ if (param_val)
+ ret = tegra_io_pad_power_disable(pad_id);
+ else
+ ret = tegra_io_pad_power_enable(pad_id);
+ if (ret < 0) {
+ dev_err(tiopi->dev,
+ "Failed to set DPD %d of pin %u: %d\n",
+ param_val, pin, ret);
+ return ret;
+ }
+ break;
+
+ default:
+ dev_err(tiopi->dev, "The parameter %d not supported\n",
+ param);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static const struct pinconf_ops tegra_io_pad_pinconf_ops = {
+ .pin_config_get = tegra_io_pad_pinconf_get,
+ .pin_config_set = tegra_io_pad_pinconf_set,
+};
+
+static struct pinctrl_desc tegra_iop_pinctrl_desc = {
+ .name = "pinctrl-tegra-io-pads",
+ .pctlops = &tegra_iop_pinctrl_ops,
+ .confops = &tegra_io_pad_pinconf_ops,
+};
+
+static int tegra_io_pads_rail_change_notify_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct tegra_io_pads_regulator_info *rinfo;
+ struct pre_voltage_change_data *vdata;
+ unsigned long int io_volt_uv, old_uv;
+ enum tegra_io_pad_voltage io_volt;
+ int ret;
+
+ rinfo = container_of(nb, struct tegra_io_pads_regulator_info,
+ regulator_nb);
+
+ switch (event) {
+ case REGULATOR_EVENT_PRE_VOLTAGE_CHANGE:
+ vdata = data;
+ if ((vdata->old_uV > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (vdata->min_uV <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT))
+ break;
+
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ TEGRA_IO_PAD_3300000UV);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ vdata->min_uV, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ case REGULATOR_EVENT_VOLTAGE_CHANGE:
+ io_volt_uv = (unsigned long)data;
+ ret = tegra_io_pad_get_voltage(rinfo->pads_cfg->pad_id);
+ if (ret < 0) {
+ dev_err(rinfo->dev, "Failed to get IO pad voltage: %d\n",
+ ret);
+ return ret;
+ }
+ old_uv = (ret == TEGRA_IO_PAD_1800000UV) ? 1800000 : 3300000;
+ if (((io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (old_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT)) ||
+ ((io_volt_uv > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (old_uv > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT)))
+ break;
+
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ TEGRA_IO_PAD_1800000UV);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ vdata->min_uV, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ case REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE:
+ io_volt_uv = (unsigned long)data;
+ io_volt = (io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) ?
+ TEGRA_IO_PAD_1800000UV : TEGRA_IO_PAD_3300000UV;
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ io_volt);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ io_volt_uv, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static int tegra_iop_pinctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct platform_device_id *id = platform_get_device_id(pdev);
+ const struct tegra_io_pad_soc_data *soc_data;
+ struct device_node *np_parent = pdev->dev.parent->of_node;
+ struct tegra_io_pads_info *tiopi;
+ int ret, i;
+
+ if (!np_parent) {
+ dev_err(dev, "PMC should be register from DT\n");
+ return -ENODEV;
+ }
+
+ soc_data = (const struct tegra_io_pad_soc_data *)id->driver_data;
+
+ tiopi = devm_kzalloc(dev, sizeof(*tiopi), GFP_KERNEL);
+ if (!tiopi)
+ return -ENOMEM;
+
+ tiopi->rinfo = devm_kzalloc(dev, sizeof(*tiopi->rinfo) *
+ soc_data->num_pads_cfg, GFP_KERNEL);
+ if (!tiopi->rinfo)
+ return -ENOMEM;
+
+ tiopi->dev = &pdev->dev;
+ pdev->dev.of_node = np_parent;
+ tiopi->soc_data = soc_data;
+
+ for (i = 0; i < soc_data->num_pads_cfg; ++i) {
+ struct tegra_io_pads_regulator_info *rinfo = tiopi->rinfo + i;
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &soc_data->pads_cfg[i];
+ struct regulator *regulator;
+ int io_volt_uv;
+ enum tegra_io_pad_voltage io_volt;
+
+ if (!pads_cfg->vsupply)
+ continue;
+
+ regulator = devm_regulator_get_optional(dev, pads_cfg->vsupply);
+ if (IS_ERR(regulator)) {
+ ret = PTR_ERR(regulator);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ continue;
+ }
+
+ io_volt_uv = regulator_get_voltage(regulator);
+ if (io_volt_uv < 0) {
+ dev_err(dev, "Failed to get voltage for rail %s: %d\n",
+ pads_cfg->vsupply, io_volt_uv);
+ return ret;
+ }
+
+ io_volt = (io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) ?
+ TEGRA_IO_PAD_1800000UV : TEGRA_IO_PAD_3300000UV;
+
+ ret = tegra_io_pad_set_voltage(pads_cfg->pad_id, io_volt);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set voltage %d of pad %s: %d\n",
+ io_volt_uv, pads_cfg->name, ret);
+ return ret;
+ }
+ rinfo->dev = tiopi->dev;
+ rinfo->regulator = regulator;
+ rinfo->pads_cfg = pads_cfg;
+
+ rinfo->regulator_nb.notifier_call =
+ tegra_io_pads_rail_change_notify_cb;
+ ret = devm_regulator_register_notifier(regulator,
+ &rinfo->regulator_nb);
+ if (ret < 0) {
+ dev_err(dev, "Failed to register regulator %s notifier: %d\n",
+ pads_cfg->name, ret);
+ return ret;
+ }
+ }
+
+ tegra_iop_pinctrl_desc.pins = tiopi->soc_data->pins_desc;
+ tegra_iop_pinctrl_desc.npins = tiopi->soc_data->num_pins_desc;
+ platform_set_drvdata(pdev, tiopi);
+
+ tiopi->pctl = devm_pinctrl_register(dev, &tegra_iop_pinctrl_desc,
+ tiopi);
+ if (IS_ERR(tiopi->pctl)) {
+ ret = PTR_ERR(tiopi->pctl);
+ dev_err(dev, "Failed to register io-pad pinctrl driver: %d\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+#define TEGRA124_PAD_INFO_TABLE(_entry_) \
+ _entry_(0, "audio", AUDIO, true, NULL), \
+ _entry_(1, "bb", BB, true, NULL), \
+ _entry_(2, "cam", CAM, true, NULL), \
+ _entry_(3, "comp", COMP, true, NULL), \
+ _entry_(4, "csia", CSIA, true, NULL), \
+ _entry_(5, "csib", CSIB, true, NULL), \
+ _entry_(6, "csie", CSIE, true, NULL), \
+ _entry_(7, "dsi", DSI, true, NULL), \
+ _entry_(8, "dsib", DSIB, true, NULL), \
+ _entry_(9, "dsic", DSIC, true, NULL), \
+ _entry_(10, "dsid", DSID, true, NULL), \
+ _entry_(11, "hdmi", HDMI, true, NULL), \
+ _entry_(12, "hsic", HSIC, true, NULL), \
+ _entry_(13, "hv", HV, true, NULL), \
+ _entry_(14, "lvds", LVDS, true, NULL), \
+ _entry_(15, "mipi-bias", MIPI_BIAS, true, NULL), \
+ _entry_(16, "nand", NAND, true, NULL), \
+ _entry_(17, "pex-bias", PEX_BIAS, true, NULL), \
+ _entry_(18, "pex-clk1", PEX_CLK1, true, NULL), \
+ _entry_(19, "pex-clk2", PEX_CLK2, true, NULL), \
+ _entry_(20, "pex-ctrl", PEX_CNTRL, true, NULL), \
+ _entry_(21, "sdmmc1", SDMMC1, true, NULL), \
+ _entry_(22, "sdmmc3", SDMMC3, true, NULL), \
+ _entry_(23, "sdmmc4", SDMMC4, true, NULL), \
+ _entry_(24, "sys-ddc", SYS_DDC, true, NULL), \
+ _entry_(25, "uart", UART, true, NULL), \
+ _entry_(26, "usb0", USB0, true, NULL), \
+ _entry_(27, "usb1", USB1, true, NULL), \
+ _entry_(28, "usb2", USB2, true, NULL), \
+ _entry_(29, "usb-bias", USB_BIAS, true, NULL)
+
+#define TEGRA210_PAD_INFO_TABLE(_entry_) \
+ _entry_(0, "audio", AUDIO, true, "vddio-audio"), \
+ _entry_(1, "audio-hv", AUDIO_HV, true, "vddio-audio-hv"), \
+ _entry_(2, "cam", CAM, true, "vddio-cam"), \
+ _entry_(3, "csia", CSIA, true, NULL), \
+ _entry_(4, "csib", CSIB, true, NULL), \
+ _entry_(5, "csic", CSIC, true, NULL), \
+ _entry_(6, "csid", CSID, true, NULL), \
+ _entry_(7, "csie", CSIE, true, NULL), \
+ _entry_(8, "csif", CSIF, true, NULL), \
+ _entry_(9, "dbg", DBG, true, "vddio-dbg"), \
+ _entry_(10, "debug-nonao", DEBUG_NONAO, true, NULL), \
+ _entry_(11, "dmic", DMIC, true, "vddio-dmic"), \
+ _entry_(12, "dp", DP, true, NULL), \
+ _entry_(13, "dsi", DSI, true, NULL), \
+ _entry_(14, "dsib", DSIB, true, NULL), \
+ _entry_(15, "dsic", DSIC, true, NULL), \
+ _entry_(16, "dsid", DSID, true, NULL), \
+ _entry_(17, "emmc", SDMMC4, true, NULL), \
+ _entry_(18, "emmc2", EMMC2, true, NULL), \
+ _entry_(19, "gpio", GPIO, true, "vddio-gpio"), \
+ _entry_(20, "hdmi", HDMI, true, NULL), \
+ _entry_(21, "hsic", HSIC, true, NULL), \
+ _entry_(22, "lvds", LVDS, true, NULL), \
+ _entry_(23, "mipi-bias", MIPI_BIAS, true, NULL), \
+ _entry_(24, "pex-bias", PEX_BIAS, true, NULL), \
+ _entry_(25, "pex-clk1", PEX_CLK1, true, NULL), \
+ _entry_(26, "pex-clk2", PEX_CLK2, true, NULL), \
+ _entry_(27, "pex-ctrl", PEX_CNTRL, false, "vddio-pex-ctrl"), \
+ _entry_(28, "sdmmc1", SDMMC1, true, "vddio-sdmmc1"), \
+ _entry_(29, "sdmmc3", SDMMC3, true, "vddio-sdmmc3"), \
+ _entry_(30, "spi", SPI, true, "vddio-spi"), \
+ _entry_(31, "spi-hv", SPI_HV, true, "vddio-spi-hv"), \
+ _entry_(32, "uart", UART, true, "vddio-uart"), \
+ _entry_(33, "usb0", USB0, true, NULL), \
+ _entry_(34, "usb1", USB1, true, NULL), \
+ _entry_(35, "usb2", USB2, true, NULL), \
+ _entry_(36, "usb3", USB3, true, NULL), \
+ _entry_(37, "usb-bias", USB_BIAS, true, NULL)
+
+#define TEGRA_IO_PAD_INFO(_id, _name, _pad_id, _lpstate, _vsupply) \
+ { \
+ .name = _name, \
+ .pins = {(_id)}, \
+ .pad_id = TEGRA_IO_PAD_##_pad_id, \
+ .vsupply = (_vsupply), \
+ .support_low_power_state = (_lpstate), \
+ }
+
+static const struct tegra_io_pads_cfg_info tegra124_io_pads_cfg_info[] = {
+ TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
+};
+
+static const struct tegra_io_pads_cfg_info tegra210_io_pads_cfg_info[] = {
+ TEGRA210_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
+};
+
+#define TEGRA_IO_PAD_DESC(_id, _name, _pad_id, _lpstate, _vsupply) \
+ PINCTRL_PIN(_id, _name)
+
+static const struct pinctrl_pin_desc tegra124_io_pads_pinctrl_desc[] = {
+ TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_DESC),
+};
+
+static const struct pinctrl_pin_desc tegra210_io_pads_pinctrl_desc[] = {
+ TEGRA210_PAD_INFO_TABLE(TEGRA_IO_PAD_DESC),
+};
+
+static const struct tegra_io_pad_soc_data tegra124_io_pad_soc_data = {
+ .pins_desc = tegra124_io_pads_pinctrl_desc,
+ .num_pins_desc = ARRAY_SIZE(tegra124_io_pads_pinctrl_desc),
+ .pads_cfg = tegra124_io_pads_cfg_info,
+ .num_pads_cfg = ARRAY_SIZE(tegra124_io_pads_cfg_info),
+};
+
+static const struct tegra_io_pad_soc_data tegra210_io_pad_soc_data = {
+ .pins_desc = tegra210_io_pads_pinctrl_desc,
+ .num_pins_desc = ARRAY_SIZE(tegra210_io_pads_pinctrl_desc),
+ .pads_cfg = tegra210_io_pads_cfg_info,
+ .num_pads_cfg = ARRAY_SIZE(tegra210_io_pads_cfg_info),
+};
+
+static const struct platform_device_id tegra_io_pads_dev_id[] = {
+ {
+ .name = "pinctrl-t124-io-pad",
+ .driver_data = (kernel_ulong_t)&tegra124_io_pad_soc_data,
+ }, {
+ .name = "pinctrl-t210-io-pad",
+ .driver_data = (kernel_ulong_t)&tegra210_io_pad_soc_data,
+ }, {
+ },
+};
+MODULE_DEVICE_TABLE(platform, tegra_io_pads_dev_id);
+
+static struct platform_driver tegra_iop_pinctrl_driver = {
+ .driver = {
+ .name = "pinctrl-tegra-io-pad",
+ },
+ .probe = tegra_iop_pinctrl_probe,
+ .id_table = tegra_io_pads_dev_id,
+};
+
+module_platform_driver(tegra_iop_pinctrl_driver);
+
+MODULE_DESCRIPTION("NVIDIA TEGRA IO pad Control Driver");
+MODULE_AUTHOR("Laxman Dewangan <ldewangan@nvidia.com>");
+MODULE_LICENSE("GPL v2");
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/9] drm/i915: Add per-pipe plane identifier
From: Ville Syrjälä @ 2016-11-09 13:23 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx
In-Reply-To: <20161109005320.GE6536@intel.com>
On Tue, Nov 08, 2016 at 04:53:20PM -0800, Matt Roper wrote:
> On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that happened nonetheless, so
> > let's fix it up by splitting the two into two enums.
> >
> > We'll also want something we just directly pass to various register
> > offset macros and whatnot on SKL+. So let's make this new thing work for that.
> > Currently we pass intel_plane->plane for the "sprites" and just a
> > hardcoded zero for the "primary" planes. We want to get rid of that
> > hardocoding so that we can share the same code for all planes (apart
> > from the legacy cursor of course).
> >
> > [1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
> >
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> So the goal here is to make intel_plane->plane represent which of the
> system's primary planes (A, B, or C) the plane structure refers to?
It's the index we pass to DSPCNTR & co. On SKL+ we theoretically don't
need it since we index most of plane registers via the plane->id, but
there are still a few exceptions left perhaps, which is why I didn't
outlaw it fully on SKL+ at this point.
> >From a quick Cocci test, it looks like there's only a single use of the
> value for that purpose in our driver (in primary_get_hw_state). I think
> all of the other calls to DSPCNTR are actually using crtc->plane as
> their index, which should have the same value. Would it make more sense
> to just drop intel_plane->plane entirely and switch the last user over
> to crtc->plane so that we're not carrying around a structure field that
> is either bogus or empty on the majority of the platform's planes?
crtc->plane needs to die. We want the planes to be independent of crtcs
on pre-g4x.
>
> While we're at it, we could rename 'enum plane' to something like 'enum
> primary_plane' to make it extra clear what its purpose is and avoid
> future confusion. And maybe a similar rename to crtc->plane as well.
> We use the standalone term 'plane' in a generic manner in too many
> places in our driver and it means something slightly different
> everywhere...
I think I want to resurrect plane->plane for cursor at some point since
on gen2/3 cursors can move between pipes as well. Alternative we could
add some other enum for those.
Anyways, I was thinking of calling this thing legacy_plane_id or
something like that, but couldn't really convince myself that any
particular name was good, so I left it as is for now.
>
>
> Matt
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 28 +++++++++++++++++++++-------
> > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > drivers/gpu/drm/i915/intel_sprite.c | 1 +
> > 4 files changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 30777dee3f9c..2451b88b1e82 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder transcoder)
> > }
> >
> > /*
> > - * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> > - * number of planes per CRTC. Not all platforms really have this many planes,
> > - * which means some arrays of size I915_MAX_PLANES may have unused entries
> > - * between the topmost sprite plane and the cursor plane.
> > + * Global legacy plane identifier. Valid only for primary/sprite
> > + * planes on pre-g4x, and only for primary planes on g4x+.
> > */
> > enum plane {
> > - PLANE_A = 0,
> > + PLANE_A,
> > PLANE_B,
> > PLANE_C,
> > - PLANE_CURSOR,
> > - I915_MAX_PLANES,
> > };
> > #define plane_name(p) ((p) + 'A')
> >
> > #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + (s) + 'A')
> >
> > +/*
> > + * Per-pipe plane identifier.
> > + * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> > + * number of planes per CRTC. Not all platforms really have this many planes,
> > + * which means some arrays of size I915_MAX_PLANES may have unused entries
> > + * between the topmost sprite plane and the cursor plane.
> > + *
> > + * This is expected to be passed to various register macros
> > + * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
> > + */
> > +enum plane_id {
> > + PLANE_PRIMARY,
> > + PLANE_SPRITE0,
> > + PLANE_SPRITE1,
> > + PLANE_CURSOR,
> > + I915_MAX_PLANES,
> > +};
> > +
> > enum port {
> > PORT_NONE = -1,
> > PORT_A = 0,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 10869360cfdc..b318119330e8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15008,6 +15008,7 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
> > primary->plane = (enum plane) !pipe;
> > else
> > primary->plane = (enum plane) pipe;
> > + primary->id = PLANE_PRIMARY;
> > primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
> > primary->check_plane = intel_check_primary_plane;
> >
> > @@ -15203,6 +15204,7 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
> > cursor->max_downscale = 1;
> > cursor->pipe = pipe;
> > cursor->plane = pipe;
> > + cursor->id = PLANE_CURSOR;
> > cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
> > cursor->check_plane = intel_check_cursor_plane;
> > cursor->update_plane = intel_update_cursor_plane;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 398195bf6dd1..58fc8e1d2aa8 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -767,7 +767,8 @@ struct intel_plane_wm_parameters {
> >
> > struct intel_plane {
> > struct drm_plane base;
> > - int plane;
> > + u8 plane;
> > + enum plane_id id;
> > enum pipe pipe;
> > bool can_scale;
> > int max_downscale;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > index 5e4eb7cafef0..4b44863a07c2 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1126,6 +1126,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
> >
> > intel_plane->pipe = pipe;
> > intel_plane->plane = plane;
> > + intel_plane->id = PLANE_SPRITE0 + plane;
> > intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
> > intel_plane->check_plane = intel_check_sprite_plane;
> >
> > --
> > 2.7.4
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.