Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > I think drivers/misc is not the right place for this, but I'm not completely > sure what is. drivers/firmware would be better at least, but virt/fsl might > also be ok. I don't think it's correct to think of a hypervisor as firmware, so I don't think drivers/firmware is better. I'm not sure that creating virt/fsl and putting the driver in there is a good idea, because it will be the only driver in that directory. Unlike KVM, this driver is just a collection of front-ends to our hypervisor API. The actual hypervisor is completely separate. That's why I put it in drivers/misc, because it's just a single driver with a miscellaneous collection of interfaces. We also don't want to have any Kconfig options that "turn on" hypervisor support. I've intentionally made support for the hypervisor part of the normal platform code, and the device tree is used to determine whether that code is active or not. So virt/fsl seems like overkill to me. > I'm not convinced that an ioctl interface is the right way to work with > device tree properties. A more natural way would be to export it as > a file system, or maybe as a flattened device tree blob (the latter option > would require changing the hypervisor interface, which might not be > possible). As Scott said, this is just a front-end to the hypervisor API, and we already have applications that depend on the ioctl interface. Considering that this driver is specific to the Freescale hypervisor, so I don't see any harm in using ioctls. > For an ioctl, please follow the normal pattern of defining a separate > structure for each case, no union. Ok. This will break our existing applications, but it's a minor fix. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > For an ioctl, please follow the normal pattern of defining a separate > structure for each case, no union. > > You can use a void __user * in the common ioctl function, and pass that > to the typed argument list in the specific functions. I have a GPL question. This header file is currently licensed under the GPL v2 only. Does that mean that any application that includes this header file so that it can talk to the driver/hypervisor also needs to be licensed under the GPL? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: >> > I don't think it's correct to think of a hypervisor as firmware, so I don't >> > think drivers/firmware is better. >> > >> > I'm not sure that creating virt/fsl and putting the driver in there is a >> > good >> > idea, because it will be the only driver in that directory. Unlike KVM, >> > this >> > driver is just a collection of front-ends to our hypervisor API. The >> > actual >> > hypervisor is completely separate. That's why I put it in drivers/misc, >> > because >> > it's just a single driver with a miscellaneous collection of interfaces. > Ok, fair enough. If nobody has a strong preference any other way, just make it > drivers/firmware then. Did you mean to say drivers/misc? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] [v3] drivers/misc: introduce Freescale hypervisor management driver
The Freescale hypervisor management driver provides several services to
drivers and applications related to the Freescale hypervisor:
1. An ioctl interface for querying and managing partitions
2. A file interface to reading incoming doorbells
3. An interrupt handler for shutting down the partition upon receiving the
shutdown doorbell from a manager partition
4. An interface for receiving callbacks when a managed partition shuts down.
Signed-off-by: Timur Tabi
---
drivers/misc/Kconfig |7 +
drivers/misc/Makefile |1 +
drivers/misc/fsl_hypervisor.c | 954
include/linux/Kbuild |1 +
include/linux/fsl_hypervisor.h | 214 +
5 files changed, 1177 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/fsl_hypervisor.c
create mode 100644 include/linux/fsl_hypervisor.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index d80dcde..3e016b3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -216,6 +216,13 @@ config ENCLOSURE_SERVICES
driver (SCSI/ATA) which supports enclosures
or a SCSI enclosure device (SES) to use these services.
+config FSL_HV_MANAGER
+ tristate "Freescale hypervisor management driver"
+ depends on FSL_SOC
+ help
+ This driver allows applications to communicate with the Freescale
+ Hypervisor.
+
config SGI_XP
tristate "Support communication between SGI SSIs"
depends on NET
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 848e846..d93bd76 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o
obj-$(CONFIG_SGI_IOC4) += ioc4.o
obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
+obj-$(CONFIG_FSL_HV_MANAGER) += fsl_hypervisor.o
obj-$(CONFIG_KGDB_TESTS) += kgdbts.o
obj-$(CONFIG_SGI_XP) += sgi-xp/
obj-$(CONFIG_SGI_GRU) += sgi-gru/
diff --git a/drivers/misc/fsl_hypervisor.c b/drivers/misc/fsl_hypervisor.c
new file mode 100644
index 000..64d38379
--- /dev/null
+++ b/drivers/misc/fsl_hypervisor.c
@@ -0,0 +1,954 @@
+/*
+ * Freescale Hypervisor Management Driver
+
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * This driver contains functions to support the Freescale hypervisor.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+static BLOCKING_NOTIFIER_HEAD(failover_subscribers);
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_RESTART
+ *
+ * Restart a running partition
+ */
+static long ioctl_restart(struct fsl_hv_ioctl_restart __user *p)
+{
+ struct fsl_hv_ioctl_restart param;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_restart)))
+ return -EFAULT;
+
+ param.ret = fh_partition_restart(param.partition);
+
+ if (copy_to_user(&p->ret, ¶m.ret, sizeof(__u32)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_STATUS
+ *
+ * Query the status of a partition
+ */
+static long ioctl_status(struct fsl_hv_ioctl_status __user *p)
+{
+ struct fsl_hv_ioctl_status param;
+ u32 status;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_status)))
+ return -EFAULT;
+
+ param.ret = fh_partition_get_status(param.partition, &status);
+ if (!param.ret)
+ param.status = status;
+
+ if (copy_to_user(p, ¶m, sizeof(struct fsl_hv_ioctl_status)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_START
+ *
+ * Start a stopped partition.
+ */
+static long ioctl_start(struct fsl_hv_ioctl_start __user *p)
+{
+ struct fsl_hv_ioctl_start param;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_start)))
+ return -EFAULT;
+
+ param.ret = fh_partition_start(param.partition, param.entry_point,
+ param.load);
+
+ if (copy_to_user(&p->ret, ¶m.ret, sizeof(__u32)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_STOP
+ *
+ * Stop a running partition
+ */
+static long ioctl_stop(struct fsl_hv_ioctl_stop __user *p)
+{
+ struct fsl_hv_ioctl_stop param;
+
+ /* Get the parameters from the user */
+ if (copy_
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > Sorry, I misread your first sentence above. I thought you said that you prefer > drivers/firmware over virt/fsl. drivers/misc is definitely the wrong > place for this, please choose a better one. Maybe drivers/virt/ ? I'll be more than happy to go with the consensus, but I don't think it makes sense to create a new directory just for this one, limited-use driver. You're the only person who's complained about drivers/misc. I'm pretty sure that if I put it in drivers/virt, I'll get more complaints. I still don't understand what's wrong with drivers/misc, especially since my driver registers as a "misc" driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > When we talked about the situation of drivers/misc and drivers/char at > one of the recent conferences, a broad consensus was that they are in > need of a maintainer, which I foolishly signed up for. Deepak wanted > to send an update to the MAINTAINERS file for this (I guess I can do > that too, since he must have forgotten about it), but the main idea is > that I'm there to say no to any driver that someone tries to add there, > unless there are really good reasons why it is actually a good place > to live for that driver. Can you give me an example of a driver that *does* belong in drivers/misc? Frankly, I just don't see what's wrong with a repository of various drivers that don't really belong anywhere else. And what about my concern that my driver will be the only one in drivers/virt? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > I have no doubt that more of these will come. Chris Metcalf is currently > looking for a home for his tilera hypervisor drivers, and we have the > microsoft hyperv drivers in drivers/staging, so they will hopefully > move to a proper place later. We also have similar drivers in other > places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c > or parts of drivers/xen. Alright, drivers/virt it is. I'll post a v4 once everyone else has had a chance to comment on v3. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > For the spi flash driver that goes through the hypervisor abstraction, > I think drivers/virt/tile would be better than driver/platform/tile, > but we should really have a new "abstract flash character driver" subsystem > for that. Why should it matter that the SPI flash driver goes through the hypervisor abstration? One of the patches in this patchset is a TTY driver that goes through the Freescale hypervisor. I put the drivers in drivers/tty. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p1022ds: fix audio-related properties in the device tree
On the Freescale P1022DS reference board, the SSI audio controller is
connected in "asynchronous" mode to the codec's clocks, so the device tree
needs an "fsl,ssi-asynchronous" property.
Also remove the clock-frequency property from the wm8776 node, because
the clock is enabled only if U-Boot enables it, and U-Boot will set the
property if the clock is enabled. A future version of the P1022DS audio
driver will configure the clock itself, but for now, the driver should
not be told that the clock is running when it isn't.
Signed-off-by: Timur Tabi
---
Without this patch, audio is broken on the P1022DS. I don't know why I missed
this on the initial version of the device tree. I will also post this
patch for the -stable trees.
arch/powerpc/boot/dts/p1022ds.dts |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
index 4f685a7..9255e58 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -209,8 +209,10 @@
wm8776:codec@1a {
compatible = "wlf,wm8776";
reg = <0x1a>;
- /* MCLK source is a stand-alone oscillator */
- clock-frequency = <12288000>;
+ /*
+* clock-frequency will be set by U-Boot if
+* the clock is enabled.
+*/
};
};
@@ -281,6 +283,7 @@
fsl,playback-dma = <&dma00>;
fsl,capture-dma = <&dma01>;
fsl,fifo-depth = <16>;
+ fsl,ssi-asynchronous;
};
dma@c300 {
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v2] powerpc/p1022ds: fix audio-related properties in the device tree
On the Freescale P1022DS reference board, the SSI audio controller is
connected in "asynchronous" mode to the codec's clocks, so the device tree
needs an "fsl,ssi-asynchronous" property.
Also remove the clock-frequency property from the wm8776 node, because
the clock is enabled only if U-Boot enables it, and U-Boot will set the
property if the clock is enabled. A future version of the P1022DS audio
driver will configure the clock itself, but for now, the driver should
not be told that the clock is running when it isn't.
Also fix the FIFO depth to 15, instead of 16.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1022ds.dts |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
index 4f685a7..98d9426 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -209,8 +209,10 @@
wm8776:codec@1a {
compatible = "wlf,wm8776";
reg = <0x1a>;
- /* MCLK source is a stand-alone oscillator */
- clock-frequency = <12288000>;
+ /*
+* clock-frequency will be set by U-Boot if
+* the clock is enabled.
+*/
};
};
@@ -280,7 +282,8 @@
codec-handle = <&wm8776>;
fsl,playback-dma = <&dma00>;
fsl,capture-dma = <&dma01>;
- fsl,fifo-depth = <16>;
+ fsl,fifo-depth = <15>;
+ fsl,ssi-asynchronous;
};
dma@c300 {
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc/p1022ds: add missing iounmap calls to platform file
The platform file for the Freecale P1022DS reference board is not freeing
the ioremap() mapping of the PIXIS and global utilities nodes it creates.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 7eb5c40..e083e1f 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -129,6 +129,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char
*gamma_table_base)
static void p1022ds_set_monitor_port(int monitor_port)
{
struct device_node *pixis_node;
+ void __iomem *pixis;
u8 __iomem *brdcfg1;
pixis_node = of_find_compatible_node(NULL, NULL, "fsl,p1022ds-pixis");
@@ -137,12 +138,12 @@ static void p1022ds_set_monitor_port(int monitor_port)
return;
}
- brdcfg1 = of_iomap(pixis_node, 0);
- if (!brdcfg1) {
+ pixis = of_iomap(pixis_node, 0);
+ if (!pixis) {
pr_err("p1022ds: could not map ngPIXIS registers\n");
return;
}
- brdcfg1 += 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
+ brdcfg1 = pixis + 9;/* BRDCFG1 is at offset 9 in the ngPIXIS */
switch (monitor_port) {
case 0: /* DVI */
@@ -158,6 +159,8 @@ static void p1022ds_set_monitor_port(int monitor_port)
default:
pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
}
+
+ iounmap(pixis);
}
/**
@@ -201,6 +204,8 @@ void p1022ds_set_pixel_clock(unsigned int pixclock)
/* Enable the clock and set the pxclk */
setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+
+ iounmap(guts);
}
/**
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Add the drivers/virt directory, which houses drivers that support
virtualization environments, and add the Freescale hypervisor management
driver.
The Freescale hypervisor management driver provides several services to
drivers and applications related to the Freescale hypervisor:
1. An ioctl interface for querying and managing partitions
2. A file interface to reading incoming doorbells
3. An interrupt handler for shutting down the partition upon receiving the
shutdown doorbell from a manager partition
4. An interface for receiving callbacks when a managed partition shuts down.
Signed-off-by: Timur Tabi
---
drivers/Kconfig|2 +
drivers/Makefile |3 +
drivers/virt/Kconfig | 22 +
drivers/virt/Makefile |5 +
drivers/virt/fsl_hypervisor.c | 961
include/linux/Kbuild |1 +
include/linux/fsl_hypervisor.h | 214 +
7 files changed, 1208 insertions(+), 0 deletions(-)
create mode 100644 drivers/virt/Kconfig
create mode 100644 drivers/virt/Makefile
create mode 100644 drivers/virt/fsl_hypervisor.c
create mode 100644 include/linux/fsl_hypervisor.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 557a469..0371680 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -122,4 +122,6 @@ source "drivers/hwspinlock/Kconfig"
source "drivers/clocksource/Kconfig"
+source "drivers/virt/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 3f135b6..306c80e5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -119,3 +119,6 @@ obj-y += ieee802154/
obj-y += clk/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+
+# Virtualization drivers
+obj-$(VIRT_DRIVERS)+= virt/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
new file mode 100644
index 000..b0cb0b6
--- /dev/null
+++ b/drivers/virt/Kconfig
@@ -0,0 +1,22 @@
+#
+# Virtualization support drivers
+#
+
+menuconfig VIRT_DRIVERS
+ bool "Virtualization drivers"
+ ---help---
+ Say Y here to get to see options for device drivers that support
+ virtualization environments.
+
+ If you say N, all options in this submenu will be skipped and
disabled.
+
+if VIRT_DRIVERS
+
+config FSL_HV_MANAGER
+ tristate "Freescale hypervisor management driver"
+ depends on FSL_SOC
+ help
+ This driver allows applications to communicate with the Freescale
+ Hypervisor.
+
+endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
new file mode 100644
index 000..c47f04d
--- /dev/null
+++ b/drivers/virt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for drivers that support virtualization
+#
+
+obj-$(CONFIG_FSL_HV_MANAGER) += fsl_hypervisor.o
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
new file mode 100644
index 000..2b41d48
--- /dev/null
+++ b/drivers/virt/fsl_hypervisor.c
@@ -0,0 +1,961 @@
+/*
+ * Freescale Hypervisor Management Driver
+
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * This driver contains functions to support the Freescale hypervisor.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+static BLOCKING_NOTIFIER_HEAD(failover_subscribers);
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_RESTART
+ *
+ * Restart a running partition
+ */
+static long ioctl_restart(struct fsl_hv_ioctl_restart __user *p)
+{
+ struct fsl_hv_ioctl_restart param;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_restart)))
+ return -EFAULT;
+
+ param.ret = fh_partition_restart(param.partition);
+
+ if (copy_to_user(&p->ret, ¶m.ret, sizeof(__u32)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_STATUS
+ *
+ * Query the status of a partition
+ */
+static long ioctl_status(struct fsl_hv_ioctl_status __user *p)
+{
+ struct fsl_hv_ioctl_status param;
+ u32 status;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_status)))
+ return -EFAULT;
+
+ param.ret = fh_partition_get_status(param.partition, &status);
+ if (!param.ret)
+ param.status = status;
+
+ if (copy_to_user(p, ¶m, sizeof(struct fsl_hv_ioctl_status)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_START
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote:
>> Add the drivers/virt directory, which houses drivers that support
>> > virtualization environments, and add the Freescale hypervisor management
>> > driver.
> It can't go in linux/virt or linux/virt/fsl instead? why drivers/ ?
>
> or maybe linux/virt should be drivers/virt ?
I knew this would happen. The reason I put it in drivers/virt is because Arnd
told me to put it there. At this point, I don't give a damn where it goes, but
I wish you all would come to a consensus.
>> > + * ALTERNATIVELY, this software may be distributed under the terms of the
>> > + * GNU General Public License ("GPL") as published by the Free Software
>> > + * Foundation, either version 2 of that License or (at your option) any
>> > + * later version.
> Why any later version? I thought that decided that Linux
> is GPL v2.
Um, you do realize that this isn't the only file in the kernel that is
v2-or-later? Try this command on the Linux source, and you'll see what I mean:
grep -r "\(at your option\)" *
I'm dual-licensing the header file because it's meant for applications as well
as the kernel. That way, no one needs to worry whether #including the header
file in his application will taint the app with the GPL.
>> > +/**
>> > + * struct fsl_hv_ioctl_restart: restart a partition
> This syntax should be (for all structs here):
>
> * struct fsl_hv_ioctl_restart - restart a partition
>
> but the struct fields/members do use ':' instead of '-'.
>
> Darn, I checked Documentation/kernel-doc-nano-HOWTO.txt and it says
> that ':' is optional but '-' is needed, so you could use
>
> * struct fsl_hv_ioctl_restart: - restart a partition
>
Ok, I'll change it.
>> > + * fsl_hv_event_register -- register a callback for failover events
> Documentation/kernel-doc-nano-HOWTO.txt says to use one '-' here, not 2.
Ok. I'll review that document and make sure my comments conform. I guess I
just wasn't paying attention at the time.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote: > But it sounds like virt/ needs virt/host/ and virt/guest/ to me. I'm okay with that idea, except there's a consensus that drivers should be in drivers/. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote: >> > I'm okay with that idea, except there's a consensus that drivers should be >> > in >> > drivers/. >> > > Like sound/ ? My understanding is that this is something that's considered broken and should be fixed, but I don't know what the holdup is. > but what makes it a "driver"? That's a good point. Ok, so maybe I don't have any really good answers here. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > Then get rid of all the code that takes apart the ioctl command numbers > again and just do a switch/case based on the command. I still need to keep that code to maintain binary compatibility with existing applications that pass the union as a parameter. I'll fix that after we've updated the applications. But we have a chicken-or-the-egg problem where we need the same application to work with the new and old ioctl interface for a period of time. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver
Add the drivers/virt directory, which houses drivers that support
virtualization environments, and add the Freescale hypervisor management
driver.
The Freescale hypervisor management driver provides several services to
drivers and applications related to the Freescale hypervisor:
1. An ioctl interface for querying and managing partitions
2. A file interface to reading incoming doorbells
3. An interrupt handler for shutting down the partition upon receiving the
shutdown doorbell from a manager partition
4. A kernel interface for receiving callbacks when a managed partition
shuts down.
Signed-off-by: Timur Tabi
---
drivers/Kconfig|2 +
drivers/Makefile |3 +
drivers/virt/Kconfig | 32 ++
drivers/virt/Makefile |5 +
drivers/virt/fsl_hypervisor.c | 983
include/linux/Kbuild |1 +
include/linux/fsl_hypervisor.h | 231 ++
7 files changed, 1257 insertions(+), 0 deletions(-)
create mode 100644 drivers/virt/Kconfig
create mode 100644 drivers/virt/Makefile
create mode 100644 drivers/virt/fsl_hypervisor.c
create mode 100644 include/linux/fsl_hypervisor.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 557a469..0371680 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -122,4 +122,6 @@ source "drivers/hwspinlock/Kconfig"
source "drivers/clocksource/Kconfig"
+source "drivers/virt/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 3f135b6..bbe2918 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -119,3 +119,6 @@ obj-y += ieee802154/
obj-y += clk/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+
+# Virtualization drivers
+obj-$(CONFIG_VIRT_DRIVERS) += virt/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
new file mode 100644
index 000..2dcdbc9
--- /dev/null
+++ b/drivers/virt/Kconfig
@@ -0,0 +1,32 @@
+#
+# Virtualization support drivers
+#
+
+menuconfig VIRT_DRIVERS
+ bool "Virtualization drivers"
+ ---help---
+ Say Y here to get to see options for device drivers that support
+ virtualization environments.
+
+ If you say N, all options in this submenu will be skipped and
disabled.
+
+if VIRT_DRIVERS
+
+config FSL_HV_MANAGER
+ tristate "Freescale hypervisor management driver"
+ depends on FSL_SOC
+ help
+ The Freescale hypervisor management driver provides several services
+ to drivers and applications related to the Freescale hypervisor:
+
+ 1) An ioctl interface for querying and managing partitions.
+
+ 2) A file interface to reading incoming doorbells.
+
+ 3) An interrupt handler for shutting down the partition upon
+receiving the shutdown doorbell from a manager partition.
+
+ 4) A kernel interface for receiving callbacks when a managed
+partition shuts down.
+
+endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
new file mode 100644
index 000..c47f04d
--- /dev/null
+++ b/drivers/virt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for drivers that support virtualization
+#
+
+obj-$(CONFIG_FSL_HV_MANAGER) += fsl_hypervisor.o
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
new file mode 100644
index 000..086085f
--- /dev/null
+++ b/drivers/virt/fsl_hypervisor.c
@@ -0,0 +1,983 @@
+/*
+ * Freescale Hypervisor Management Driver
+
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * The Freescale hypervisor management driver provides several services to
+ * drivers and applications related to the Freescale hypervisor:
+ *
+ * 1. An ioctl interface for querying and managing partitions.
+ *
+ * 2. A file interface to reading incoming doorbells.
+ *
+ * 3. An interrupt handler for shutting down the partition upon receiving the
+ *shutdown doorbell from a manager partition.
+ *
+ * 4. A kernel interface for receiving callbacks when a managed partition
+ *shuts down.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+static BLOCKING_NOTIFIER_HEAD(failover_subscribers);
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_RESTART
+ *
+ * Restart a running partition
+ */
+static long ioctl_restart(struct fsl_hv_ioctl_restart __user *p)
+{
+ struct fsl_hv_ioctl_restart param;
+
+ /* Get the parameters from the user */
+ if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_restart)))
+ return -EFAULT;
+
+ par
Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote:
>> > +enum fsl_hv_ioctl_cmd {
>> > + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct
>> > fsl_hv_ioctl_restart),
>> > + FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct
>> > fsl_hv_ioctl_status),
>> > + FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
>> > + FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
>> > + FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>> > + FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>> > + FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>> > + FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>> > +};
> Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with
> conflict!).
If I change it from 0, I'm going to break binary compatibility with our apps. I
agree that maybe I shouldn't have picked 0, but considering how many conflicts
there already are, I wonder what the point is. Even if I pick a number that is
currently not listed in the chart, that doesn't mean that it's actually not
being used, or that it won't conflict in the future.
So is it okay to stick with 0, or do I need to pick a new number?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver
Arnd Bergmann wrote:
> As mentioned, it would be easier and more readable to just do
>
> switch(cmd) {
> case FSL_HV_IOCTL_PARTITION_RESTART:
> ...
>
> case FSL_HV_IOCTL_PARTITION_GET_STATUS;
> ...
>
> There is no need to check the bits individually when you can simply
> compare the command number.
But this will break backwards compatibility with older applications that used
the union as the size parameter. Although these applications won't compile with
the new header file, older already-compiled applications still work.
I will eventually update the applications to use the new header file, and at
that point I will modify the switch statement as you suggest. But until then,
I'd like to keep the code as-is.
>> > +enum fsl_hv_ioctl_cmd {
>> > + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct
>> > fsl_hv_ioctl_restart),
>> > + FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct
>> > fsl_hv_ioctl_status),
>> > + FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct
>> > fsl_hv_ioctl_start),
>> > + FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct
>> > fsl_hv_ioctl_stop),
>> > + FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>> > + FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>> > + FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>> > + FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>> > +};
> Using a #define here is usually preferred because then you can use #ifdef in
> a user
> application to check if a given value has been assigned.
You're right -- I had enum on the brain.
> More importantly, the code you have chose (0) conflicts with existing drivers
> (frame buffer, scsi and wavefront among others). Please chose a free one and
> add it to Documentation/ioctl/ioctl-number.txt in the same patch.
Ok, I was really hoping to avoid doing this. Like I said, binary compatibility
is important, and changing the type will break my existing apps. Are you
insisting that I pick a new number?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > The lesson to learn here is obviously not to ship binaries of applications > to customers before the driver has been merged in a mainline kernel. Believe me, I know this, but unfortunately I have no control over every aspect of our development cycle. > The best way out that I can see is to make the driver carry the proper > interface in the upstream version, but to have a private patch to support > both interface versions in the kernel you ship on machines that require > backwards compatibility. Once you have phased out the user application, > you can then drop that patch and use the upstream version of the > interfaces. I think I can make that work. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver
Greg KH wrote: > Why is binary compatibility important? Isn't this a brand new driver > for a brand new system? What userspace tools are out there in the wild > for such a thing? This driver (and the hypervisor it talks to, plus the apps, etc) has been in internal development for three years. There hasn't been a lot of effort internally to release this software upstream until recently. I personally have been complaining about it for quite some time, but I have no control over our internal release process. Even when the hardware has been announced and available for purchase, the BSP is sometimes only available under NDA. Eventually, everything is publicly released, and most of the code is pushed upstream, but it's a long and painful struggle at times. My concern has been dealing with the headaches of bug reports from customers, etc as they upgrade their kernel but not their apps, and then wonder why nothing works. But as Arnd pointed out, it really isn't as big of deal as I make it out to be. I can maintain compatibility internally. I blame my allergy medicine. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver
Add the drivers/virt directory, which houses drivers that support virtualization environments, and add the Freescale hypervisor management driver. The Freescale hypervisor management driver provides several services to drivers and applications related to the Freescale hypervisor: 1. An ioctl interface for querying and managing partitions 2. A file interface to reading incoming doorbells 3. An interrupt handler for shutting down the partition upon receiving the shutdown doorbell from a manager partition 4. A kernel interface for receiving callbacks when a managed partition shuts down. Signed-off-by: Timur Tabi --- Documentation/ioctl/ioctl-number.txt |1 + drivers/Kconfig |2 + drivers/Makefile |3 + drivers/virt/Kconfig | 32 ++ drivers/virt/Makefile|5 + drivers/virt/fsl_hypervisor.c| 937 ++ include/linux/Kbuild |1 + include/linux/fsl_hypervisor.h | 241 + 8 files changed, 1222 insertions(+), 0 deletions(-) create mode 100644 drivers/virt/Kconfig create mode 100644 drivers/virt/Makefile create mode 100644 drivers/virt/fsl_hypervisor.c create mode 100644 include/linux/fsl_hypervisor.h diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index a0a5d82..9b8a8bd 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include FileComments <mailto:ru...@rustcorp.com.au> 0xAE all linux/kvm.h Kernel-based Virtual Machine <mailto:k...@vger.kernel.org> +0xAF 00-1F linux/fsl_hypervisor.h Freescale hypervisor 0xB0 all RATIO devices in development: <mailto:v...@ratio.de> 0xB1 00-1F PPPoX <mailto:mostr...@styx.uwaterloo.ca> diff --git a/drivers/Kconfig b/drivers/Kconfig index 557a469..0371680 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -122,4 +122,6 @@ source "drivers/hwspinlock/Kconfig" source "drivers/clocksource/Kconfig" +source "drivers/virt/Kconfig" + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 3f135b6..bbe2918 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -119,3 +119,6 @@ obj-y += ieee802154/ obj-y += clk/ obj-$(CONFIG_HWSPINLOCK) += hwspinlock/ + +# Virtualization drivers +obj-$(CONFIG_VIRT_DRIVERS) += virt/ diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig new file mode 100644 index 000..2dcdbc9 --- /dev/null +++ b/drivers/virt/Kconfig @@ -0,0 +1,32 @@ +# +# Virtualization support drivers +# + +menuconfig VIRT_DRIVERS + bool "Virtualization drivers" + ---help--- + Say Y here to get to see options for device drivers that support + virtualization environments. + + If you say N, all options in this submenu will be skipped and disabled. + +if VIRT_DRIVERS + +config FSL_HV_MANAGER + tristate "Freescale hypervisor management driver" + depends on FSL_SOC + help + The Freescale hypervisor management driver provides several services + to drivers and applications related to the Freescale hypervisor: + + 1) An ioctl interface for querying and managing partitions. + + 2) A file interface to reading incoming doorbells. + + 3) An interrupt handler for shutting down the partition upon +receiving the shutdown doorbell from a manager partition. + + 4) A kernel interface for receiving callbacks when a managed +partition shuts down. + +endif diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile new file mode 100644 index 000..c47f04d --- /dev/null +++ b/drivers/virt/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for drivers that support virtualization +# + +obj-$(CONFIG_FSL_HV_MANAGER) += fsl_hypervisor.o diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c new file mode 100644 index 000..1d3b8eb --- /dev/null +++ b/drivers/virt/fsl_hypervisor.c @@ -0,0 +1,937 @@ +/* + * Freescale Hypervisor Management Driver + + * Copyright (C) 2008-2011 Freescale Semiconductor, Inc. + * Author: Timur Tabi + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * The Freescale hypervisor management driver provides several services to + * drivers and applications related to the Freescale hypervisor: + * + * 1. An ioctl interface for querying and managing partitions. + * + * 2. A file interface to reading incoming doorbells. + * + * 3. An interrupt
[PATCH] powerpc/85xx: add hypervisor config entries to corenet_smp_defconfig
CONFIG_PPC_EPAPR_HV_BYTECHAN adds support for the Freescale hypervisor byte channel tty driver. CONFIG_VIRT_DRIVERS and CONFIG_FSL_HV_MANAGER add support for the Freescale hypervisor management driver. Signed-off-by: Timur Tabi --- arch/powerpc/configs/corenet32_smp_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index de9bd16..75fd124 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -108,6 +108,7 @@ CONFIG_FSL_PQ_MDIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_SERIO_LIBPS2=y # CONFIG_LEGACY_PTYS is not set +CONFIG_PPC_EPAPR_HV_BYTECHAN=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y @@ -149,6 +150,8 @@ CONFIG_STAGING=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y # CONFIG_STAGING_EXCLUDE_BUILD is not set +CONFIG_VIRT_DRIVERS=y +CONFIG_FSL_HV_MANAGER=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -- 1.7.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mapping an executable page
Thomas De Schampheleire wrote:
> * However, if you jump to an address in that page, you'll have to make
> sure that the entire code that executes is mapped (make map_size large
> enough).
Well, that seems obvious.
> * When that range spanned multiple pages, I faced the issue of only
> one page being actually mapped in the TLBs. My assumption is that the
> call to __ioremap not necessarily updates the TLBs, but mainly some
> kernel-internal tables. The actual TLB mapping presumably happens when
> a data exception occurs.
Hmmm I find that surprising. Memory allocated via ioremap() is supposed to
be available in interrupt handlers, where TLB mappings can't be created
on-the-fly. I'm not sure that your observation is correct.
> * Therefore, to make sure that the mapping I intended with __ioremap()
> is actually reflected in the TLB tables, I added dummy reads of each
> page in the TLB, prior to jumping to the boot code, as follows:
> /* make sure memory is read, once every 4Kbyte is enough */
> for (p = vaddr; p < vaddr + map_size; p += 0x1000) {
You should at least use PAGE_SIZE instead of 0x1000.
> unsigned long dummy = *(volatile unsigned long *)p;
> (void)dummy;
> }
>
> * After these changes (make sure all code is mapped + make sure to
> read all pages so that the TLBs are updated), my scenario works fine.
I still find it hard to believe that this is necessary.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mapping an executable page
Timur Tabi wrote: > Hmmm I find that surprising. Memory allocated via ioremap() is supposed > to > be available in interrupt handlers, where TLB mappings can't be created > on-the-fly. I'm not sure that your observation is correct. Ok, it turns out I'm wrong. As long as the page is in the page tables (i.e. physically present in RAM), you can take a TLB miss in an interrupt handler, and the TLB miss handler will create a TLB for you. This means that ... > unsigned long dummy = *(volatile unsigned long *)p; > (void)dummy; > } > > * After these changes (make sure all code is mapped + make sure to > read all pages so that the TLBs are updated), my scenario works fine. is not going to work reliably, because it assumes that the TLBs created by your multiple ioremap() calls will still be there when your code is called. If you use just a single ioremap() call, but still touch every page, that should work for you just as well. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
The Freescale hypervisor does not allow guests to write to the timebase
registers (virtualizing the timebase register was deemed too complicated),
so don't try to synchronize the timebase registers when we're running
under the hypervisor.
This typically happens when kexec support is enabled.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p3041_ds.c | 11 +++
arch/powerpc/platforms/85xx/p4080_ds.c | 11 +++
arch/powerpc/platforms/85xx/p5020_ds.c | 11 +++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p3041_ds.c
b/arch/powerpc/platforms/85xx/p3041_ds.c
index c0242bc..8b651dfe 100644
--- a/arch/powerpc/platforms/85xx/p3041_ds.c
+++ b/arch/powerpc/platforms/85xx/p3041_ds.c
@@ -40,6 +40,9 @@
static int __init p3041_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P3041DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p3041_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+* Disable the timebase sync operations because we can't write
+* to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p4080_ds.c
b/arch/powerpc/platforms/85xx/p4080_ds.c
index 32ea5eb..ae859ab 100644
--- a/arch/powerpc/platforms/85xx/p4080_ds.c
+++ b/arch/powerpc/platforms/85xx/p4080_ds.c
@@ -39,6 +39,9 @@
static int __init p4080_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P4080DS"))
return 1;
@@ -50,6 +53,14 @@ static int __init p4080_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+* Disable the timebase sync operations because we can't write
+* to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p5020_ds.c
b/arch/powerpc/platforms/85xx/p5020_ds.c
index 2ea9ccc..d951618 100644
--- a/arch/powerpc/platforms/85xx/p5020_ds.c
+++ b/arch/powerpc/platforms/85xx/p5020_ds.c
@@ -40,6 +40,9 @@
static int __init p5020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P5020DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p5020_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+* Disable the timebase sync operations because we can't write
+* to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
Scott Wood wrote: > FWIW, it's not supported under KVM either -- though we don't support an SMP > guest under KVM yet, and KVM silently ignores it rather than logs errors as > the FSL HV does. Does KVM set the root compatible to "fsl,P4080DS-hv"? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] Add support for RTC device: pt7c4338 in rtc-ds1307.c
Priyanka Jain wrote: > config RTC_DRV_DS1307 > - tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025" > + tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, > PT7C4338" > help > If you say yes here you get support for various compatible RTC > chips (often with battery backup) connected with I2C. This driver > should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00, > - EPSON RX-8025 and probably other chips. In some cases the RTC > - must already have been initialized (by manufacturing or a > + EPSON RX-8025, PT7C4338 and probably other chips. In some cases > + the RTC must already have been initialized (by manufacturing or a > bootloader). I think you should probably drop the Kconfig change, too. It already says, "and probably other chips", and you're also just bloating the summary line. We can't list every possible Dallas-compatible RTC chip here. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v3] Add support for RTC device: pt7c4338 in rtc-ds1307.c
Priyanka Jain wrote: > PT7C4338 chip is being manufactured by Pericom Technology Inc. > It is a serial real-time clock which provides: > 1)Low-power clock/calendar. > 2)Programmable square-wave output. > It has 56 bytes of nonvolatile RAM. > Its register set is same as that of rtc device: DS1307. > > > Signed-off-by: Priyanka Jain Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl-diu-fb: remove the ioctl interface
The ioctl interface in the Freescale DIU framebuffer driver is just a
collection of miscellaneous functions which were only used in a one-time
demo application that was never distributed. Plus, the ioctls were spread
across two types (both conflicting), and the demo app didn't even use all
of them.
Removing the ioctl interface also allows us to clean up the header file and
remove other unusued stuff.
Signed-off-by: Timur Tabi
---
There's a warning about dummy_ad_addr that will be fixed in a future patch.
Documentation/ioctl/ioctl-number.txt |2 -
drivers/video/fsl-diu-fb.c | 157 ++
include/linux/fsl-diu-fb.h | 94
3 files changed, 44 insertions(+), 209 deletions(-)
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 3a46e36..6c83c07 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -108,7 +108,6 @@ Code Seq#(hex) Include FileComments
'E'00-0F xen/evtchn.hconflict!
'F'all linux/fb.h conflict!
'F'01-02 drivers/scsi/pmcraid.h conflict!
-'F'20 drivers/video/fsl-diu-fb.h conflict!
'F'20 drivers/video/intelfb/intelfb.h conflict!
'F'20 linux/ivtvfb.h conflict!
'F'20 linux/matroxfb.hconflict!
@@ -147,7 +146,6 @@ Code Seq#(hex) Include FileComments
'M'01-16 mtd/mtd-abi.h conflict!
and drivers/mtd/mtdchar.c
'M'01-03 drivers/scsi/megaraid/megaraid_sas.h
-'M'00-0F drivers/video/fsl-diu-fb.h conflict!
'N'00-1F drivers/usb/scanner.h
'O' 00-06 mtd/ubi-user.h UBI
'P'all linux/soundcard.h conflict!
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..db2abaf 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -37,6 +37,50 @@
#include
#include "edid.h"
+/* Minimum value that the pixel clock can be set to in pico seconds
+ * This is determined by platform clock/3 where the minimum platform
+ * clock is 533MHz. This gives 5629 pico seconds.
+ */
+#define MIN_PIX_CLK5629
+#define MAX_PIX_CLK96096
+
+#define FSL_AOI_NUM6 /* 5 AOIs and one dummy AOI */
+
+/* INT_STATUS/INT_MASK field descriptions */
+#define INT_VSYNC 0x01/* Vsync interrupt */
+#define INT_VSYNC_WB 0x02/* Vsync interrupt for write back operation */
+#define INT_UNDRUN 0x04/* Under run exception interrupt */
+#define INT_PARERR 0x08/* Display parameters error interrupt */
+#define INT_LS_BF_VS 0x10/* Lines before vsync. interrupt */
+
+/* Panels'operation modes */
+#define MFB_TYPE_OUTPUT0 /* Panel output to display */
+#define MFB_TYPE_OFF 1 /* Panel off */
+#define MFB_TYPE_WB2 /* Panel written back to memory */
+#define MFB_TYPE_TEST 3 /* Panel generate color bar */
+
+/* HW cursor parameters */
+#define MAX_CURS 32
+
+struct diu_hw {
+ struct diu *diu_reg;
+ spinlock_t reg_lock;
+ __u32 mode; /* DIU operation mode */
+};
+
+struct diu_addr {
+ __u8 __iomem *vaddr;/* Virtual address */
+ dma_addr_t paddr; /* Physical address */
+ __u32 offset;
+};
+
+struct diu_pool {
+ struct diu_addr ad;
+ struct diu_addr gamma;
+ struct diu_addr pallete;
+ struct diu_addr cursor;
+};
+
/*
* These parameters give default parameters
* for video output 1024x768,
@@ -991,118 +1035,6 @@ static int fsl_diu_blank(int blank_mode, struct fb_info
*info)
return 0;
}
-static int fsl_diu_ioctl(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
-{
- struct mfb_info *mfbi = info->par;
- struct diu_ad *ad = mfbi->ad;
- struct mfb_chroma_key ck;
- unsigned char global_alpha;
- struct aoi_display_offset aoi_d;
- __u32 pix_fmt;
- void __user *buf = (void __user *)arg;
-
- if (!arg)
- return -EINVAL;
- switch (cmd) {
- case MFB_SET_PIXFMT:
- if (copy_from_user(&pix_fmt, buf, sizeof(pix_fmt)))
- return -EFAULT;
- ad->pix_fmt = pix_fmt;
- pr_debug("Set pixel format to 0x%08x\n", ad->pix_fmt);
- break;
- case MFB_GET_PIXFMT:
- pix_fmt = ad->pix_fmt;
- if (copy_to_user(buf, &pix_fmt, sizeof(pix_fmt)))
- return -EFAULT;
- pr_debug("get pixel format 0x%08x\n", ad->pix_fmt);
- break;
- case MFB_SET_AOID:
- if (copy_from_user(&aoi_d, buf, sizeof(aoi_d)))
-
Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
Kumar Gala wrote: >> > >> > Well, not exactly. Paul wants to break that up since we're adding some >> > primitive support for 201 HV mode too (for 970's). Last we discussed, >> > the plan was to go for a generic HV mode bit and a separate bit for the >> > version. >> > >> > Cheers, >> > Ben. > Any ETA on Paul's intro of the FTR bit? If not I'll pull this into my 'next' > tree and we can clean up later. Just FYI, this particular patch is because of a limitation in the Freescale hypervisor. It's not because we're running in guest mode. If the hypervisor provided full emulation of the timebase register, then we wouldn't need this patch. The same can be said of KVM or any other hypervisor. So a generic HV mode bit is not going to help me, unless there's also a bit that's specific to our hypervisor. And even then, we would need some way to differentiate among different versions of our hypervisor, in case some future version adds timebase support. We currently use the device tree for all this, so I'm not sure what a FTR bit will gain us. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/7] [v2] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
Timur Tabi wrote: > The ePAPR embedded hypervisor specification provides an API for "byte > channels", which are serial-like virtual devices for sending and receiving > streams of bytes. This driver provides Linux kernel support for byte > channels via three distinct interfaces: > > 1) An early-console (udbg) driver. This provides early console output > through a byte channel. The byte channel handle must be specified in a > Kconfig option. > > 2) A normal console driver. Output is sent to the byte channel designated > for stdout in the device tree. The console driver is for handling kernel > printk calls. > > 3) A tty driver, which is used to handle user-space input and output. The > byte channel used for the console is designated as the default tty. > > Signed-off-by: Timur Tabi I know you guys are busy, but can I get an ACK or two on this patch, if there are no issues with it? It's the only one of the seven that doesn't have one. I think v2 has addressed all of the concerns raised on version 1. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Connecting SGMII PHY to eTSEC1 on P1022
Felix Radensky wrote: > What am I doing wrong ? Can you debug the PHY driver to see if it's getting called and trying to talk to the PHY itself? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/86xx: improve calculation of DIU pixel clock on the MPC8610 HPCD
mpc8610hpcd_set_pixel_clock() calculates the correct value of the PXCLK
bits in the CLKDVDR register for a given pixel clock rate. The code which
performs this calculation is overly complicated and includes an error
estimation routine that doesn't work most of the time anyway. Replace the
code with the simpler routine that's currently used on the P1022DS.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 107 ---
1 files changed, 48 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index a896511..74e018e 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -39,12 +39,19 @@
#include
#include
#include
+#include
#include "mpc86xx.h"
static struct device_node *pixis_node;
static unsigned char *pixis_bdcfg0, *pixis_arch;
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x8000
+#define CLKDVDR_PXCKINV0x1000
+#define CLKDVDR_PXCKDLY0x0600
+#define CLKDVDR_PXCLK_MASK 0x001F
+
#ifdef CONFIG_SUSPEND
static irqreturn_t mpc8610_sw9_irq(int irq, void *data)
{
@@ -205,72 +212,54 @@ void mpc8610hpcd_set_monitor_port(int monitor_port)
bdcfg[monitor_port]);
}
+/**
+ * mpc8610hpcd_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
void mpc8610hpcd_set_pixel_clock(unsigned int pixclock)
{
- u32 __iomem *clkdvdr;
- u32 temp;
- /* variables for pixel clock calcs */
- ulong bestval, bestfreq, speed_ccb, minpixclock, maxpixclock;
- ulong pixval;
- long err;
- int i;
-
- clkdvdr = ioremap(get_immrbase() + 0xe0800, sizeof(u32));
- if (!clkdvdr) {
- printk(KERN_ERR "Err: can't map clock divider register!\n");
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts_86xx __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,mpc8610-guts");
+ if (!guts_np) {
+ pr_err("mpc8610hpcd: missing global utilties device node\n");
return;
}
- /* Pixel Clock configuration */
- speed_ccb = fsl_get_sys_freq();
-
- /* Calculate the pixel clock with the smallest error */
- /* calculate the following in steps to avoid overflow */
- pr_debug("DIU pixclock in ps - %d\n", pixclock);
- temp = 10/pixclock;
- temp *= 1000;
- pixclock = temp;
- pr_debug("DIU pixclock freq - %u\n", pixclock);
-
- temp = pixclock * 5 / 100;
- pr_debug("deviation = %d\n", temp);
- minpixclock = pixclock - temp;
- maxpixclock = pixclock + temp;
- pr_debug("DIU minpixclock - %lu\n", minpixclock);
- pr_debug("DIU maxpixclock - %lu\n", maxpixclock);
- pixval = speed_ccb/pixclock;
- pr_debug("DIU pixval = %lu\n", pixval);
-
- err = 1;
- bestval = pixval;
- pr_debug("DIU bestval = %lu\n", bestval);
-
- bestfreq = 0;
- for (i = -1; i <= 1; i++) {
- temp = speed_ccb / ((pixval+i) + 1);
- pr_debug("DIU test pixval i= %d, pixval=%lu, temp freq. = %u\n",
- i, pixval, temp);
- if ((temp < minpixclock) || (temp > maxpixclock))
- pr_debug("DIU exceeds monitor range (%lu to %lu)\n",
- minpixclock, maxpixclock);
- else if (abs(temp - pixclock) < err) {
- pr_debug("Entered the else if block %d\n", i);
- err = abs(temp - pixclock);
- bestval = pixval+i;
- bestfreq = temp;
- }
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("mpc8610hpcd: could not map global utilties device\n");
+ return;
}
- pr_debug("DIU chose = %lx\n", bestval);
- pr_debug("DIU error = %ld\n NomPixClk ", err);
- pr_debug("DIU: Best Freq = %lx\n", bestfreq);
- /* Modify PXCLK in GUTS CLKDVDR */
- pr_debug("DIU: Current value of CLKDVDR = 0x%08x\n", (*clkdvdr));
- temp = (*clkdvdr) & 0x2000;
- *clkdvdr = temp;/* turn off clock */
- *clkdvdr = temp | 0x8000 | (((bestval) & 0x1F) << 16);
- pr_debug("DIU: Modified value of CLKDVDR = 0x%08x\n", (*clkdvdr));
- i
[PATCH 1/2] powerpc/86xx: enable the framebuffer console on the MPC8610 HPCD
Enable framebuffer console support by default in the defconfig on the Freescale MPC8610 HPCD reference board. This allows the boot messages to be shown on the video display. Signed-off-by: Timur Tabi --- arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig index 036bfb2..0db9ba0 100644 --- a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig +++ b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig @@ -89,6 +89,11 @@ CONFIG_I2C_MPC=y CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FB_FSL_DIU=y +CONFIG_VGACON_SOFT_SCROLLBACK=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FONTS=y +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_MIXER_OSS=y -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
Scott Wood wrote: > From Power ISA 2.06B, book III-E, section 9.2.1: > > Virtualized Implementation Note: > > In virtualized implementations, TBU and TBL are > read-only. But does that mean that a guest should never be allowed to modify a virtualized timebase register, even if the hypervisor can support it? >> > So a generic HV mode bit is not going to help me, unless there's also a bit >> > that's specific to our hypervisor. And even then, we would need some way >> > to >> > differentiate among different versions of our hypervisor, in case some >> > future >> > version adds timebase support. > That's very unlikely to happen. I know. I was just being architecturally pedantic. > Ideally we would avoid doing this sync even when not running under a > hypervisor, as long as firmware has done the sync, and kexec hasn't messed > it up. Besides being a waste of boot time, the firmware's sync is > probably tighter since it can use a platform-specific mechanism to start all > the timebases at once. I agree with that, but for now, I need to work around that kexec "limitation". -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: enable the framebuffer console for the defconfigs
Enable framebuffer console support by default in the defconfigs for the Freescale 85xx-based reference board. This allows the boot messages to be shown on the video display on the P1022DS. Signed-off-by: Timur Tabi --- arch/powerpc/configs/mpc85xx_defconfig |4 arch/powerpc/configs/mpc85xx_smp_defconfig |4 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index 96b89df..b212e3d 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -128,6 +128,10 @@ CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FB_FSL_DIU=y # CONFIG_VGA_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FONTS=y +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SUPPORT_OLD_API is not set diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index de65841..87fbb2e 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -130,6 +130,10 @@ CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FB_FSL_DIU=y # CONFIG_VGA_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FONTS=y +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SUPPORT_OLD_API is not set -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: clamp the P1022DS DIU pixel clock to allowed values
To ensure that the DIU pixel clock will not be set to an invalid value, clamp the PXCLK divider to the allowed range (2-255). This also acts as a limiter for the pixel clock. Signed-off-by: Timur Tabi --- arch/powerpc/platforms/85xx/p1022_ds.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c index e083e1f..266b3aa 100644 --- a/arch/powerpc/platforms/85xx/p1022_ds.c +++ b/arch/powerpc/platforms/85xx/p1022_ds.c @@ -195,8 +195,13 @@ void p1022ds_set_pixel_clock(unsigned int pixclock) do_div(temp, pixclock); freq = temp; - /* pixclk is the ratio of the platform clock to the pixel clock */ + /* +* 'pxclk' is the ratio of the platform clock to the pixel clock. +* This number is programmed into the CLKDVDR register, and the valid +* range of values is 2-255. +*/ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq); + pxclk = clamp_t(u32, pxclk, 2, 255); /* Disable the pixel clock, and set it to non-inverted and no delay */ clrbits32(&guts->clkdvdr, -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl-diu-fb: remove check for pixel clock ranges
The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
the pixel clock. These values, however, are true only for one platform
clock rate (533MHz) and only for the MPC8610. So the actual range for
the pixel clock is chip-specific, which means the current values are almost
always wrong. The chance of an out-of-range pixel clock being used are also
remote.
Rather than try to detect an out-of-range clock in the DIU driver, we depend
on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
to clamp the pixel clock to a supported value.
Signed-off-by: Timur Tabi
---
drivers/video/fsl-diu-fb.c | 16
include/linux/fsl-diu-fb.h |6 --
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..0acc7d6 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -555,8 +555,6 @@ static void adjust_aoi_size_position(struct
fb_var_screeninfo *var,
static int fsl_diu_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
- unsigned long htotal, vtotal;
-
pr_debug("check_var xres: %d\n", var->xres);
pr_debug("check_var yres: %d\n", var->yres);
@@ -635,20 +633,6 @@ static int fsl_diu_check_var(struct fb_var_screeninfo *var,
break;
}
- /* If the pixclock is below the minimum spec'd value then set to
-* refresh rate for 60Hz since this is supported by most monitors.
-* Refer to Documentation/fb/ for calculations.
-*/
- if ((var->pixclock < MIN_PIX_CLK) || (var->pixclock > MAX_PIX_CLK)) {
- htotal = var->xres + var->right_margin + var->hsync_len +
- var->left_margin;
- vtotal = var->yres + var->lower_margin + var->vsync_len +
- var->upper_margin;
- var->pixclock = (vtotal * htotal * 6UL) / 100UL;
- var->pixclock = KHZ2PICOS(var->pixclock);
- pr_debug("pixclock set for 60Hz refresh = %u ps\n",
- var->pixclock);
- }
var->height = -1;
var->width = -1;
diff --git a/include/linux/fsl-diu-fb.h b/include/linux/fsl-diu-fb.h
index 781d467..daa9952 100644
--- a/include/linux/fsl-diu-fb.h
+++ b/include/linux/fsl-diu-fb.h
@@ -24,12 +24,6 @@
* See mpc8610fb_set_par(), map_video_memory(), and unmap_video_memory()
*/
#define MEM_ALLOC_THRESHOLD (1024*768*4+32)
-/* Minimum value that the pixel clock can be set to in pico seconds
- * This is determined by platform clock/3 where the minimum platform
- * clock is 533MHz. This gives 5629 pico seconds.
- */
-#define MIN_PIX_CLK 5629
-#define MAX_PIX_CLK 96096
#include
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
Felix Radensky wrote: > On P1022DS both ethernet controllers are connected to RGMII PHYs > accessible via MDIO bus. Remove fixed-link property from ethernet > nodes as they only required when fixed link PHYs without MDIO bus > are used. > > Signed-off-by: Felix Radensky Acked-by: Timur Tabi Ethernet works before and after applying this patch, so all I can say is that it doesn't break anything. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/video: use strings to specify the Freescale DIU monitor port
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
on the kernel command line, the module command-line, and the sysfs "monitor"
device.
Note that changing the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-
arch/powerpc/platforms/85xx/p1022_ds.c | 47 -
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +---
arch/powerpc/sysdev/fsl_soc.h| 25 ++---
drivers/video/fsl-diu-fb.c | 73 +++--
5 files changed, 128 insertions(+), 94 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index e41ebbd..3dc62f9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -66,8 +66,8 @@ struct fsl_diu_shared_fb {
boolin_use;
};
-unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
+unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int
bits_per_pixel,
return 0x0400;
}
-void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
+char *gamma_table_base)
{
}
-void mpc512x_set_monitor_port(int monitor_port)
+void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
{
}
@@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock)
iounmap(ccm);
}
-ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf)
+enum fsl_diu_monitor_port
+mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return sprintf(buf, "0 - 5121 LCD\n");
-}
-
-int mpc512x_set_sysfs_monitor_port(int val)
-{
- return 0;
+ return FSL_DIU_PORT_DVI;
}
static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb;
@@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void)
diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port= mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
- diu_ops.show_monitor_port = mpc512x_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc512x_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
#endif
}
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 266b3aa..c01c727 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -93,8 +93,8 @@
* The Area Descriptor is a 32-bit value that determine which bits in each
* pixel are to be used for each color.
*/
-static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int
bits_per_pixel,
* On some boards, the gamma table for some ports may need to be modified.
* This is not the case on the P1022DS, so we do nothing.
*/
-static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
@@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char
*gamma_table_base)
* p1022ds_set_monitor_port: switch the output to a different monitor port
*
*/
-static void p1022ds_set_monitor_port(int monitor_port)
+static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *pixis_node;
void __iomem *pixis;
@@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port)
}
brdcfg1 = pixis + 9;/* BRDCFG1 is at offset 9 in the ngPIXIS */
- switch (monitor_port) {
- case 0: /* DVI */
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DVIEN)
[PATCH] powerpc/mpic: add support for discontiguous cores
There is one place in the MPIC driver that assumes that the cores are numbered
from 0 to n-1. However, this is not true if the CPUs are not numbered
sequentially. This can happen on a eight-core SOC where cores two and three
are removed in the device tree. So instead of blindly looping, we iterate
over the discovered CPUs and use the SMP ID as the index.
This means that we no longer ask the MPIC how many CPUs there are, so
we also delete mpic->num_cpus.
We also catch if the number of CPUs in the SOC exceeds the number that the
MPIC supports. This should never happen, of course, but it's good to be
sure.
Signed-off-by: Timur Tabi
---
arch/powerpc/include/asm/mpic.h |2 --
arch/powerpc/sysdev/mpic.c | 24 +++-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index df18989..c447025 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -273,8 +273,6 @@ struct mpic
unsigned intirq_count;
/* Number of sources */
unsigned intnum_sources;
- /* Number of CPUs */
- unsigned intnum_cpus;
/* default senses array */
unsigned char *senses;
unsigned intsenses_count;
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 58d7a53..5d80573 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1321,13 +1321,11 @@ struct mpic * __init mpic_alloc(struct device_node
*node,
mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
| MPIC_GREG_GCONF_MCK);
- /* Read feature register, calculate num CPUs and, for non-ISU
-* MPICs, num sources as well. On ISU MPICs, sources are counted
-* as ISUs are added
+ /*
+* Read feature register. For non-ISU MPICs, num sources as well. On
+* ISU MPICs, sources are counted as ISUs are added
*/
greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
- mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK)
- >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0) {
if (flags & MPIC_BROKEN_FRR_NIRQS)
mpic->num_sources = mpic->irq_count;
@@ -1337,10 +1335,18 @@ struct mpic * __init mpic_alloc(struct device_node
*node,
>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
}
+ /*
+* The MPIC driver will crash if there are more cores than we
+* can initialize, so we may as well catch that problem here.
+*/
+ BUG_ON(num_possible_cpus() > MPIC_MAX_CPUS);
+
/* Map the per-CPU registers */
- for (i = 0; i < mpic->num_cpus; i++) {
- mpic_map(mpic, node, paddr, &mpic->cpuregs[i],
-MPIC_INFO(CPU_BASE) + i * MPIC_INFO(CPU_STRIDE),
+ for_each_possible_cpu(i) {
+ unsigned int cpu = get_hard_smp_processor_id(i);
+
+ mpic_map(mpic, node, paddr, &mpic->cpuregs[cpu],
+MPIC_INFO(CPU_BASE) + cpu * MPIC_INFO(CPU_STRIDE),
0x1000);
}
@@ -1379,7 +1385,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
}
printk(KERN_INFO "mpic: Setting up MPIC \"%s\" version %s at %llx,"
" max %d CPUs\n",
- name, vers, (unsigned long long)paddr, mpic->num_cpus);
+ name, vers, (unsigned long long)paddr, num_possible_cpus());
printk(KERN_INFO "mpic: ISU size: %d, shift: %d, mask: %x\n",
mpic->isu_size, mpic->isu_shift, mpic->isu_mask);
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
Greg KH wrote: >> > 3) A tty driver, which is used to handle user-space input and output. The >> > byte channel used for the console is designated as the default tty. >> > >> > Signed-off-by: Timur Tabi > Doesn't apply at all to the tty-next tree, so I can't apply it here :( I shall take care of that right now. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
Greg KH wrote: > Doesn't apply at all to the tty-next tree, so I can't apply it here :( Um, where exactly is the tty-next tree? The only thing I see that looks like it is this: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git But the description of this tree says, "junk tree, please ignore". -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v3] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
The ePAPR embedded hypervisor specification provides an API for "byte channels", which are serial-like virtual devices for sending and receiving streams of bytes. This driver provides Linux kernel support for byte channels via three distinct interfaces: 1) An early-console (udbg) driver. This provides early console output through a byte channel. The byte channel handle must be specified in a Kconfig option. 2) A normal console driver. Output is sent to the byte channel designated for stdout in the device tree. The console driver is for handling kernel printk calls. 3) A tty driver, which is used to handle user-space input and output. The byte channel used for the console is designated as the default tty. Signed-off-by: Timur Tabi --- arch/powerpc/include/asm/udbg.h |1 + arch/powerpc/kernel/udbg.c |2 + drivers/tty/Kconfig | 34 ++ drivers/tty/Makefile|1 + drivers/tty/ehv_bytechan.c | 888 +++ 5 files changed, 926 insertions(+), 0 deletions(-) create mode 100644 drivers/tty/ehv_bytechan.c diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h index 58580e9..0938ac8 100644 --- a/arch/powerpc/include/asm/udbg.h +++ b/arch/powerpc/include/asm/udbg.h @@ -53,6 +53,7 @@ extern void __init udbg_init_40x_realmode(void); extern void __init udbg_init_cpm(void); extern void __init udbg_init_usbgecko(void); extern void __init udbg_init_wsp(void); +extern void __init udbg_init_ehv_bc(void); #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_UDBG_H */ diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c index 23d65ab..e5e63a6 100644 --- a/arch/powerpc/kernel/udbg.c +++ b/arch/powerpc/kernel/udbg.c @@ -64,6 +64,8 @@ void __init udbg_early_init(void) udbg_init_usbgecko(); #elif defined(CONFIG_PPC_EARLY_DEBUG_WSP) udbg_init_wsp(); +#elif defined(CONFIG_PPC_EARLY_DEBUG_EHV_BC) + udbg_init_ehv_bc(); #endif #ifdef CONFIG_PPC_EARLY_DEBUG diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig index bd7cc05..f1ea59b 100644 --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -350,3 +350,37 @@ config TRACE_SINK If you select this option, you need to select "Trace data router for MIPI P1149.7 cJTAG standard". + +config PPC_EPAPR_HV_BYTECHAN + tristate "ePAPR hypervisor byte channel driver" + depends on PPC + help + This driver creates /dev entries for each ePAPR hypervisor byte + channel, thereby allowing applications to communicate with byte + channels as if they were serial ports. + +config PPC_EARLY_DEBUG_EHV_BC + bool "Early console (udbg) support for ePAPR hypervisors" + depends on PPC_EPAPR_HV_BYTECHAN + help + Select this option to enable early console (a.k.a. "udbg") support + via an ePAPR byte channel. You also need to choose the byte channel + handle below. + +config PPC_EARLY_DEBUG_EHV_BC_HANDLE + int "Byte channel handle for early console (udbg)" + depends on PPC_EARLY_DEBUG_EHV_BC + default 0 + help + If you want early console (udbg) output through a byte channel, + specify the handle of the byte channel to use. + + For this to work, the byte channel driver must be compiled + in-kernel, not as a module. + + Note that only one early console driver can be enabled, so don't + enable any others if you enable this one. + + If the number you specify is not a valid byte channel handle, then + there simply will be no early console output. This is true also + if you don't boot under a hypervisor at all. diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile index ea89b0b..2953059 100644 --- a/drivers/tty/Makefile +++ b/drivers/tty/Makefile @@ -26,5 +26,6 @@ obj-$(CONFIG_ROCKETPORT) += rocket.o obj-$(CONFIG_SYNCLINK_GT) += synclink_gt.o obj-$(CONFIG_SYNCLINKMP) += synclinkmp.o obj-$(CONFIG_SYNCLINK) += synclink.o +obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o obj-y += ipwireless/ diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c new file mode 100644 index 000..e67f70b --- /dev/null +++ b/drivers/tty/ehv_bytechan.c @@ -0,0 +1,888 @@ +/* ePAPR hypervisor byte channel device driver + * + * Copyright 2009-2011 Freescale Semiconductor, Inc. + * + * Author: Timur Tabi + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * This driver support three distinct interfaces, all of which are related to + * ePAPR hypervisor byte channels. + * + * 1) An early-console (udbg) driver. This provides early console output + * through a byte channel. The byte channel handle must be specified
[PATCH] [v2] drivers/video: use strings to specify the Freescale DIU monitor port
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
on the kernel command line, the module command-line, and the sysfs "monitor"
device.
Note that changing the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi
Acked-by: Anatolij Gustschin
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-
arch/powerpc/platforms/85xx/p1022_ds.c | 47 -
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +--
arch/powerpc/sysdev/fsl_soc.h| 25 ++---
drivers/video/fsl-diu-fb.c | 74 +++---
5 files changed, 128 insertions(+), 95 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index e41ebbd..3dc62f9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -66,8 +66,8 @@ struct fsl_diu_shared_fb {
boolin_use;
};
-unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
+unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int
bits_per_pixel,
return 0x0400;
}
-void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
+char *gamma_table_base)
{
}
-void mpc512x_set_monitor_port(int monitor_port)
+void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
{
}
@@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock)
iounmap(ccm);
}
-ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf)
+enum fsl_diu_monitor_port
+mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return sprintf(buf, "0 - 5121 LCD\n");
-}
-
-int mpc512x_set_sysfs_monitor_port(int val)
-{
- return 0;
+ return FSL_DIU_PORT_DVI;
}
static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb;
@@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void)
diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port= mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
- diu_ops.show_monitor_port = mpc512x_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc512x_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
#endif
}
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 266b3aa..c01c727 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -93,8 +93,8 @@
* The Area Descriptor is a 32-bit value that determine which bits in each
* pixel are to be used for each color.
*/
-static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int
bits_per_pixel,
* On some boards, the gamma table for some ports may need to be modified.
* This is not the case on the P1022DS, so we do nothing.
*/
-static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
@@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char
*gamma_table_base)
* p1022ds_set_monitor_port: switch the output to a different monitor port
*
*/
-static void p1022ds_set_monitor_port(int monitor_port)
+static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *pixis_node;
void __iomem *pixis;
@@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port)
}
brdcfg1 = pixis + 9;/* BRDCFG1 is at offset 9 in the ngPIXIS */
- switch (monitor_port) {
- case 0: /* DVI */
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
Re: RFC: top level compatibles for virtual platforms
Yoder Stuart-B08248 wrote: > We're talking about what would be meaningful to Linux as a guest on > this platform here-- Corenet-based SoCs are similar > in various ways, like using msgsnd for IPIs, having external proxy > support, etc. > > A corenet platform created by a QEMU/KVM looks similar > to other corenet SoCs. So, I'm trying to find some generic > compatible string that describes this platform. Is there a list of these features that are 100% guaranteed to belong to a corenet platform? I'm just not comfortable using "corenet" as a basis for a feature set that has nothing to do with coherency. >> Also, if these are KVM creations, shouldn't there be a "kvm" in the >> compatible string >> somewhere? > > There is nothing KVM specific about these platforms. Any hypervisor > could create a similar virtual machine. True, but I think we're on a slippery slope, here. Virtualization allows us to create "virtual platforms" that are not well defined. Linux requires a unique compatible string for each platform. That's easy when we ship a reference board that has a unique name and a fixed, well-defined set of features. But with these virtual platforms, what does the name mean? I guess my point is back to the name "corenet". That just doesn't mean anything to me, and I don't think it means much to anyone else, either. That's why I think that maybe "kvm" should be in the string, to at least indicate that it's a virtualized environment. > A guest OS can determine specific info about the hypervisor it is > running on by looking at the /hypervisor node on the device > tree. > > We could put a generic -hv extension to indicate that this is > a virtual platform. > > "mpc85xx-hv" > "corenet-32-hv" > "corenet-64-hv" That's an improvement, but I wonder if we should just keep doing what we do with Topaz: take the actual hardware platform and add -hv to it. Of course, that conflicts with Topaz at the moment. -- Timur Tabi Linux kernel developer at Freescale -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
Scott Wood wrote: > The device tree is supposed to describe the hardware (virtual or > otherwise), not just supply what Linux wants. Perhaps there simply > shouldn't be a toplevel compatible if there's nothing appropriate to > describe there -- and fix whatever issues Linux has with that. That might be the way to go. I wonder if we can get rid of the platform file altogether, at least in some situations. > But what about this is specific to kvm (the actual hypervisor info is > already described in /hypervisor)? Then we'll have to add a platform match > for every other hypervisor out there that does the same thing. I don't know enough about KVM to answer that question. Frankly, I like the approach that Topaz takes -- add a "-hv" to the real hardware platform. The only drawback is that each platform needs to add support for virtualization, but we already have this problem with Topaz today. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/35 linux-next] tty: constify of_device_id array
On 03/16/2015 02:17 PM, Fabian Frederick wrote: of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: Fabian Frederick ... drivers/tty/serial/ucc_uart.c | 2 +- For this driver: Acked-by: Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote: > Have just sent out a patch considering the previous discussion. > http://patchwork.ozlabs.org/patch/462249/ > [PATCH] powerpc/defconfig: new way of writing defconfig The ability to merge defconfigs is a feature that's been requested by many people for a long time. Any solution should definitely NOT be PowerPC-only. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote: > > > The ability to merge configs is already there. We're just talking about > using that functionality. Why do you need a powerpc-specific way to use merge_config.sh? Other architectures have the same problem with defconfigs. Besides, wouldn't it make more sense to define a new defconfig type, like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it knows to call merge_config.sh? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
Scott Wood wrote: > >Why do you need a powerpc-specific way to use merge_config.sh? Other >architectures have the same problem with defconfigs. What are you perceiving as "powerpc-specific" about what we're proposing? Well, there's the subject of this thread, which is "new way of writing defconfigs for freescale's powerpc platforms". > Are you complaining about the actual content of which fragments to use to produce which defconfigs going in arch/powerpc? No, I'm just trying to figure out what's powerpc-specific about Lijun's proposal. >Besides, wouldn't it make more sense to define a new defconfig type, >like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it >knows to call merge_config.sh? That's already there. "make .config". Ok, so I'm definitely confused now. I have no idea what's actually being proposed, since apparently the ability to have merge configs already exists. Wouldn't it just be simpler to pass multiple defconfigs to 'make', and then 'make' will know to call merge_config.sh on them? So instead of make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make we can just do make fsl_basic_config p1_defconfig make -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
Scott Wood wrote: We want single-name config targets to still work from the user's perspective, but we want to reduce the (often imperfect) duplication under the hood. Ok, then define a new Kconfig option that merge_config.sh will look for. So in p1_defconfig, there will be this line: CONFIG_OTHER_DEFCONFIGS=fsl_basic_config -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/21/2015 12:55 PM, Scott Wood wrote: > >Ok, then define a new Kconfig option that merge_config.sh will look for. > So in p1_defconfig, there will be this line: > >CONFIG_OTHER_DEFCONFIGS=fsl_basic_config If you want to do that go ahead. In the meantime we'll use the mechanism that already exists. Dude, you are not making any sense. If there is a mechanism that already exists, then what are we talking about? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Add dedicated DMA buffer size for each cpu dai
Nicolin Chen wrote: >As the ssi is not the only cpu dai, there are esai, spdif, sai. >and imx_pcm_dma can be used by all of them. Especially ESAI need >a larger DMA buffer size. So Add dedicated DMA buffer for each cpu >dai. > >Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Acked-by: Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode
Maciej S. Szmigiero wrote:
+ if (newbinding && fsl_ssi_is_ac97(ssi_private)) {
Is the "newbinding" necessary? I thought only the original PowerPC
device trees were the only one that have the old binding, and they never
supported AC97.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode
Maciej S. Szmigiero wrote: If there isn't going to be new platforms added with old bindings then this won't be needed - I'll remove it. I would love it if someone would port those original device trees to the new binding, so that we can get rid of the old one. But we should definitely not allow new device trees with the old binding. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
Maciej S. Szmigiero wrote:
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cpu_dai_drv.symmetric_rates = 1;
+
Is this necessary? Why not just add fsl,ssi-asynchronous to the AC97
device tree node?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel][PATCH 2/2] ASoC: fsl_ssi: sound is wrong after suspend/resume
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote: > The register SFCSR is volatile, but some bits in it need to be > recovered after suspend/resume. > > Signed-off-by: Zidan Wang Shouldn't this be part of patch #1? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel][PATCH 1/2] ASoC: fsl_ssi: Add driver suspend and resume to support MEGA Fast
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> +static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case CCSR_SSI_STX0:
> + case CCSR_SSI_STX1:
> + case CCSR_SSI_SRX0:
> + case CCSR_SSI_SRX1:
> + case CCSR_SSI_SCR:
> + case CCSR_SSI_SISR:
> + case CCSR_SSI_SIER:
> + case CCSR_SSI_STCR:
> + case CCSR_SSI_SRCR:
> + case CCSR_SSI_STCCR:
> + case CCSR_SSI_SRCCR:
> + case CCSR_SSI_SFCSR:
> + case CCSR_SSI_STR:
> + case CCSR_SSI_SOR:
> + case CCSR_SSI_SACNT:
> + case CCSR_SSI_SACADD:
> + case CCSR_SSI_SACDAT:
> + case CCSR_SSI_SATAG:
> + case CCSR_SSI_STMSK:
> + case CCSR_SSI_SRMSK:
> + case CCSR_SSI_SACCST:
> + case CCSR_SSI_SACCEN:
> + case CCSR_SSI_SACCDIS:
> + return true;
> + default:
> + return false;
> + }
> +}
This should be the other way around: return true by default, and false it is
one of the few registers that is not readable.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module
Dongsheng Wang wrote: For deep sleep, the diu module will power off, when wake up from the deep sleep, the registers need to be reinitialized. Signed-off-by: Jason Jin Signed-off-by: Wang Dongsheng Acked-by: Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module
Wang Dongsheng wrote: Thanks Timur. @Scott, Could you apply this patch? You need to ask the fbdev maintainer to apply it, because it has to go through his tree. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()
Alexander Popov wrote: Initialize Freescale MPC512x DMA driver with subsys_initcall() to allow the depending drivers to call dma_request_slave_channel() during their probe. Signed-off-by: Alexander Popov Is there any way we can use -EPROBEDEFER instead? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO
Alexander Popov wrote: +- dma-names: should be "rx-tx"; Why bother, if it can only be one value? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver
Alexander Popov wrote:
+struct mpc512x_lpbfifo_request {
+ phys_addr_t bus_phys; /* physical address of some device on LPB */
Is this a phys_addr_t or a dma_addr_t? It can't be both a physical
address and a bus address.
+ void *ram_virt; /* virtual address of some region in RAM */
+ u32 size;
+ enum lpb_dev_portsize portsize;
+ enum mpc512x_lpbfifo_req_dir dir;
+ void (*callback)(struct mpc512x_lpbfifo_request *);
+};
+
+int mpc512x_lpbfifo_submit(struct mpc512x_lpbfifo_request *req);
+
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index 48bf38d..f09016f 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -10,6 +10,12 @@ config PPC_MPC512x
select USB_EHCI_BIG_ENDIAN_MMIO if USB_EHCI_HCD
select USB_EHCI_BIG_ENDIAN_DESC if USB_EHCI_HCD
+config MPC512x_LPBFIFO
+ tristate "MPC512x LocalPlus Bus FIFO driver"
+ depends on PPC_MPC512x && MPC512X_DMA
+ help
+ Enable support for Freescale MPC512x LocalPlus Bus FIFO (SCLPC).
+
config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on PPC_MPC512x
diff --git a/arch/powerpc/platforms/512x/Makefile
b/arch/powerpc/platforms/512x/Makefile
index 0169312..f47d422 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_COMMON_CLK)+= clock-commonclk.o
obj-y += mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC512x_GENERIC) += mpc512x_generic.o
+obj-$(CONFIG_MPC512x_LPBFIFO) += mpc512x_lpbfifo.o
obj-$(CONFIG_PDM360NG)+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
new file mode 100644
index 000..e6f2c6b
--- /dev/null
+++ b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
@@ -0,0 +1,560 @@
+/*
+ * The driver for Freescale MPC512x LocalPlus Bus FIFO
+ * (called SCLPC in the Reference Manual).
+ *
+ * Copyright (C) 2013-2015 Alexander Popov.
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "mpc512x_lpbfifo"
+
+struct cs_range {
+ u32 csnum;
+ u32 base; /* must be zero */
+ u32 addr;
+ u32 size;
+};
+
+static struct lpbfifo_data {
+ spinlock_t lock; /* for protecting lpbfifo_data */
+ phys_addr_t regs_phys;
+ resource_size_t regs_size;
+ struct mpc512x_lpbfifo __iomem *regs;
+ int irq;
+ struct cs_range *cs_ranges;
+ size_t cs_n;
+ struct dma_chan *chan;
+ struct mpc512x_lpbfifo_request *req;
+ dma_addr_t ram_bus_addr;
+ bool wait_lpbfifo_irq;
+ bool wait_lpbfifo_callback;
+} lpbfifo;
+
+/*
+ * A data transfer from RAM to some device on LPB is finished
+ * when both mpc512x_lpbfifo_irq() and mpc512x_lpbfifo_callback()
+ * have been called. We execute the callback registered in
+ * mpc512x_lpbfifo_request just after that.
+ * But for a data transfer from some device on LPB to RAM we don't enable
+ * LPBFIFO interrupt because clearing MPC512X_SCLPC_SUCCESS interrupt flag
+ * automatically disables LPBFIFO reading request to the DMA controller
+ * and the data transfer hangs. So the callback registered in
+ * mpc512x_lpbfifo_request is executed at the end of
mpc512x_lpbfifo_callback().
+ */
+
+/*
+ * mpc512x_lpbfifo_irq - IRQ handler for LPB FIFO
+ */
+static irqreturn_t mpc512x_lpbfifo_irq(int irq, void *param)
+{
+ struct device *d = (struct device *)param;
Please use the variable name 'dev' instead of 'd', for consistency.
+ struct mpc512x_lpbfifo_request *req = lpbfifo.req;
+ unsigned long flags;
+ u32 status;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+
+ if (!lpbfifo.regs)
+ goto end0;
+
+ if (!req || req->dir == MPC512X_LPBFIFO_REQ_DIR_READ) {
+ dev_err(d, "bogus LPBFIFO IRQ\n");
+ goto end0;
+ }
So this might be an obscure bug. The code says that "req = lpbfifo.req"
above. However, it doesn't know that this block is in a critical
section, so it will initialize 'req' not on the top line of the
function, but rather right here. That means that although you think
that you're initializing 'req' before the spin_lock_irqsave(), the code
might actually initialize it after the spin_lock_irqsave().
My suggestion is that you explicitly initialize 'req' after
spin_lock_irqsave(). Or better yet, don't use 'req' and explicitly
reference lpbfifo.req every time.
+
+ status = in_be32(&lpbfifo.regs->status);
+ if (status != MPC512X_SCLPC_SUCCESS) {
+ dev_err(d, "DMA transfer between RAM and peripheral fa
Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver
Alexander Popov wrote: The only question I have: why calling dma_unmap_single() from within a spinlock is a bad practice? I don't know, but usually functions that allocate or free memory cannot be called from within a spinlock. You need to check that. Since the MPC5121 is a single-core CPU, you might not notice if you're doing something wrong. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO
Alexander Popov wrote: I've just followed devicetree/bindings/dma/dma.txt... This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO uses a single DMA read-write channel. Should I really drop it? Hmmm, I'm not sure. Is there anything else (besides your driver) that parses this device tree node? dma.txt says this: "The specific strings that can be used are defined in the binding of the DMA client device." So this looks like it's driver-specific, but it is a required property. I guess you should keep it, but I think you should get a second opinion. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver
On 09/30/2015 04:24 PM, Alexander Popov wrote: Can you test for "!cs" here instead? +e = -EFAULT; +goto err_param; +} Unfortunately no: 0 is a valid value for Chip Select. Is it OK to leave it like that? Yes. +lpbfifo.ram_bus_addr = sg_dma_address(&sg); /* For freeing later */ +sg_dma_len(&sg) = lpbfifo.req->size; I don't think sg_dma_len() is meant to be used as an lvalue. I've double-checked and found many cases of such usage of this macro. It seems that I can't avoid it too. Ok. Driver code that has to parse #address-cells or #size-cells is usually wrong. I would not call it "parsing", I just check whether the dts-file is good. Anyway, could you give me a clue how to do better? You should use of_n_size_cells() and of_n_addr_cells(). -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] net/fsl_pq_mdio: check TBI address for consistency with mapped range
Gerlando Falauto wrote: Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb You need to remove these from patches that are emailed, and fix the pointer type comparison. Otherwise, Acked-by: Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote: The driver creates the mapping by calling irq_of_parse_and_map(), so it also has to dispose the mapping. But the easy way out is to simply use platform_get_irq() instead of irq_of_parse_map(). In this case the mapping is not managed by the device but by the of core, so the device has not to dispose the mapping. Is this a problem unique to the SSI driver? Maybe devm_free_irq() should also dispose of the mapping? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote: The driver creates the mapping by calling irq_of_parse_and_map(), so it also has to dispose the mapping. I agree with Markus, this does seem weird. It sounds like you're saying that irq_of_parse_and_map() and devm_request_irq() are incompatible. A quick grep shows the following drivers that call both functions: ata/pata_mpc52xx.c built-in.o cpufreq/exynos5440-cpufreq.c crypto/omap-sham.c dma/moxart-dma.c edac/mpc85xx_edac.c hsi/clients/nokia-modem.c i2c/busses/i2c-wmt.c input/serio/apbps2.c mmc/host/omap_hsmmc.c mmc/host/moxart-mmc.c mtd/nand/mpc5121_nfc.c net/ethernet/arc/emac_main.c net/ethernet/moxa/moxart_ether.c pci/host/pcie-rcar.c pinctrl/samsung/pinctrl-exynos5440.c pinctrl/samsung/pinctrl-exynos.c pinctrl/pinctrl-bcm2835.c spi/spi-bcm2835.c spi/spi-mpc512x-psc.c staging/xillybus/xillybus_of.c thermal/samsung/exynos_tmu.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On 12/01/2014 01:56 PM, Arnd Bergmann wrote: All other drivers that call irq_of_parse_and_map and pass that into devm_request_irq just never unmap, and their interrupts are already mapped by the platform code, so I think it's not even a leak. Does this mean that fsl_ssi.c should not be calling irq_of_parse_and_map? How else should it get the IRQ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On 12/01/2014 02:01 PM, Arnd Bergmann wrote: >Does this mean that fsl_ssi.c should not be calling >irq_of_parse_and_map? How else should it get the IRQ? platform_get_irq() Ok, but that function also calls irq_create_of_mapping(). So it still appears that the only way to get the IRQ is to map it, but then we can't use devm_request_irq(). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On 12/01/2014 02:40 PM, Fabio Estevam wrote: >Hm... that's new. But it's not really a driver issue anymore if it is done >in the core. So I guess for now just use platform_get_irq() and ignore the >other issue. With the suggested changes below, the removal of the driver works fine on a mx6: Would the mapping continue to exist after the driver is unloaded? Can you try multiple loads/unloads and see if interrupts still work? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote: > From: Madalin Bucur > > This patch series adds the Ethernet driver for the Freescale > QorIQ Data Path Acceleration Architecture (DPAA). Please fix your git-send-email configuration, so that your emails are formatted properly. This is the From: header: From: <> -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile
On Sun, Dec 20, 2015 at 2:30 PM, Maciej S. Szmigiero
wrote:
> SACNT register should be marked volatile since
> its WR and RD bits are cleared by SSI after
> completing the relevant operation.
> This unbreaks AC'97 register access.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero
These patches seem okay, but can we hold off merging them until I get
back from vacation and have a chance to review them?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile
Maciej S. Szmigiero wrote: + regmap_write(regs, CCSR_SSI_SACNT, + ssi_private->regcache_sacnt); So I'm not familiar with all of the regcache features, but I understand this patch. I was wondering if it makes sense to write the same exact value that was read previously. Isn't it possible for the WR or RD bits to change between fsl_ssi_suspend() and fsl_ssi_resume()? That is, should we be doing this instead? u32 temp; regmap_read(regs, CCSR_SSI_SACNT, &temp); temp &= 0x18; // preserve WR and RD regmap_write(regs, CCSR_SSI_SACNT, (ssi_private->regcache_sacnt & ~0x18) | temp); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] ASoC: fsl_ssi: mark some registers precious
Maciej S. Szmigiero wrote: Mark some registers precious since their reads have side effects (like clearing flags). Signed-off-by: Maciej S. Szmigiero Acked-by: Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Maciej S. Szmigiero wrote:
There is no guarantee that on fsl_ssi module load
SSI registers will have their power-on-reset values.
In fact, if the driver is reloaded the values in
registers will be whatever they were set to previously.
This fixes hard lockup on fsl_ssi module reload,
at least in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA
Fast")
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
I'm surprised that we're actually encouraging drivers to contain
hard-coded register values.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Mark Brown wrote: That's possibly problematic because the flat cache will of necessity end up with defaults (of 0 from the kzalloc()) for all the registers. You'll still have default values in the cache, though some of the behaviour around optimising syncs does change without them explicitly given. It does deal with the allocation issue but given that the issue was incorrect defaults I'd be a bit concerned. Ok, I'm confused. Granted, all of this regcache stuff was added after I stopped working on this driver, so I'm out of the loop. But it appears that the regcache cannot properly handle an uninitialized cache. I would expect it to know to perform hard reads of any registers that are uninitialized. If the regcache wants to have an initialized cache, then it should automatically perform reads an all non-volatile, non-precious registers at initialization. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Mark Brown wrote: regcache handles this fine, it's perfectly happy to just go and allocate the cache as registers get used (this is why the code that's doing the allocation exists...). What is causing problems here is that the first access to the register is happening in interrupt context so we can't do a GFP_KERNEL allocation for it. Considering how small and not-sparse the SSI register space is, would using REGCACHE_FLAT be appropriate? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Mark Brown wrote: Quite possibly (it'll be more efficient and it's intended for such use cases) but as I said in my other reply that then has the issue that it implicitly gives default values to all the registers so I'd expect we still need to handle the cache initialisation explicitly (or alternatively the hardware sync with the cache on startup). Why does REGCACHE_FLAT assume that all registers have a default value of 0? Shouldn't it have the same behavior w.r.t. cache values as REGCACHE_RBTREE? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type
Lothar Waßmann wrote: - select SND_SOC_FSL_SSI + select SND_SOC_FSL_SAI if SOC_IMX6UL + select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX I don't think this is compatible with a multiarch kernel. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type
Lothar Waßmann wrote: Why? If more than one of the IMX6 SoCs are selected, both interfaces may be selected at the same time without any harm. Oh, ok. I thought the point behind the patch was that you *souldn't* enable the the SSI driver on an i.MX6UL. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Maciej S. Szmigiero wrote:
+static const struct regmap_config fsl_ssi_regconfig_imx21 = {
+ .max_register = CCSR_SSI_SRMSK,
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .val_format_endian = REGMAP_ENDIAN_NATIVE,
+ .num_reg_defaults_raw = CCSR_SSI_SRMSK / 4 + 1,
+ .readable_reg = fsl_ssi_readable_reg,
+ .volatile_reg = fsl_ssi_volatile_reg,
+ .precious_reg = fsl_ssi_precious_reg,
+ .writeable_reg = fsl_ssi_writeable_reg,
+ .cache_type = REGCACHE_RBTREE,
+};
+
static const struct regmap_config fsl_ssi_regconfig = {
.max_register = CCSR_SSI_SACCDIS,
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
.val_format_endian = REGMAP_ENDIAN_NATIVE,
- .reg_defaults = fsl_ssi_reg_defaults,
- .num_reg_defaults = ARRAY_SIZE(fsl_ssi_reg_defaults),
+ .num_reg_defaults_raw = CCSR_SSI_SACCDIS / 4 + 1,
.readable_reg = fsl_ssi_readable_reg,
.volatile_reg = fsl_ssi_volatile_reg,
.precious_reg = fsl_ssi_precious_reg,
Is this really necessary? Why do we need separate register configs for
one specific SOC? There are already too many "if
(some_stupid_imx_variant)" blocks in this driver.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for cache initialization may not be safe.
Also, a "MXC 91221 only" comment before these regs in FSL tree
(drivers/mxc/ssi/registers.h) seems to confirm that these registers
aren't present at least on some SSI (or SoC) models.
Can't we just mark them as precious or something, so that we don't have
to have two structures?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Maciej S. Szmigiero wrote:
On 17.01.2016 15:16, Maciej S. Szmigiero wrote:
On 17.01.2016 06:16, Timur Tabi wrote:
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for cache initialization may not be safe.
Also, a "MXC 91221 only" comment before these regs in FSL tree
(drivers/mxc/ssi/registers.h) seems to confirm that these registers
aren't present at least on some SSI (or SoC) models.
Can't we just mark them as precious or something, so that we don't have to have
two structures?
Looks like it can be done with just one static regmap config struct
used then as template - I will post updated patch.
Updated patch:
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 40dfd8a36484..105de76dd2fc 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -112,20 +112,6 @@ struct fsl_ssi_rxtx_reg_val {
struct fsl_ssi_reg_val tx;
};
-static const struct reg_default fsl_ssi_reg_defaults[] = {
- {CCSR_SSI_SCR, 0x},
- {CCSR_SSI_SIER,0x3003},
- {CCSR_SSI_STCR,0x0200},
- {CCSR_SSI_SRCR,0x0200},
- {CCSR_SSI_STCCR, 0x0004},
- {CCSR_SSI_SRCCR, 0x0004},
- {CCSR_SSI_SACNT, 0x},
- {CCSR_SSI_STMSK, 0x},
- {CCSR_SSI_SRMSK, 0x},
- {CCSR_SSI_SACCEN, 0x},
- {CCSR_SSI_SACCDIS, 0x},
-};
-
static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -190,8 +176,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
.val_bits = 32,
.reg_stride = 4,
.val_format_endian = REGMAP_ENDIAN_NATIVE,
- .reg_defaults = fsl_ssi_reg_defaults,
- .num_reg_defaults = ARRAY_SIZE(fsl_ssi_reg_defaults),
+ .num_reg_defaults_raw = CCSR_SSI_SACCDIS / 4 + 1,
Replace "4" with "sizeof(uint32_t).
.readable_reg = fsl_ssi_readable_reg,
.volatile_reg = fsl_ssi_volatile_reg,
.precious_reg = fsl_ssi_precious_reg,
@@ -201,6 +186,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
struct fsl_ssi_soc_data {
bool imx;
+ bool imx21regs;
Please add a comment explaining why this is needed.
bool offline_config;
u32 sisr_write_mask;
};
@@ -295,6 +281,7 @@ struct fsl_ssi_private {
static struct fsl_ssi_soc_data fsl_ssi_mpc8610 = {
.imx = false,
+ .imx21regs = false,
This is unnecessary. The default is already 0 (false).
.offline_config = true,
.sisr_write_mask = CCSR_SSI_SISR_RFRC | CCSR_SSI_SISR_TFRC |
CCSR_SSI_SISR_ROE0 | CCSR_SSI_SISR_ROE1 |
@@ -303,12 +290,14 @@ static struct fsl_ssi_soc_data fsl_ssi_mpc8610 = {
static struct fsl_ssi_soc_data fsl_ssi_imx21 = {
.imx = true,
+ .imx21regs = true,
.offline_config = true,
.sisr_write_mask = 0,
};
static struct fsl_ssi_soc_data fsl_ssi_imx35 = {
.imx = true,
+ .imx21regs = false,
Same here.
.offline_config = true,
.sisr_write_mask = CCSR_SSI_SISR_RFRC | CCSR_SSI_SISR_TFRC |
CCSR_SSI_SISR_ROE0 | CCSR_SSI_SISR_ROE1 |
@@ -317,6 +306,7 @@ static struct fsl_ssi_soc_data fsl_ssi_imx35 = {
static struct fsl_ssi_soc_data fsl_ssi_imx51 = {
.imx = true,
+ .imx21regs = false,
.offline_config = false,
.sisr_write_mask = CCSR_SSI_SISR_ROE0 | CCSR_SSI_SISR_ROE1 |
CCSR_SSI_SISR_TUE0 | CCSR_SSI_SISR_TUE1,
@@ -586,8 +576,11 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi_private
*ssi_private)
*/
regmap_write(regs, CCSR_SSI_SACNT,
CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV);
- regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
- regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
+
+ if (!ssi_private->soc->imx21regs) {
+ regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
+ regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
+ }
This needs a comment.
/*
* Enable SSI, Transmit and Receive. AC97 has to communicate with the
@@ -1397,6 +1390,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *iomem;
char name[64];
+ struct regmap_config regconfig = fsl_ssi_regconfig;
of_id = of_match_device(fsl_ssi_ids, &pdev->dev);
if (!of_id || !of_id->data)
@@ -1444,15 +1438,22 @@ static int fsl_ssi_probe(struct platform_device *pdev)
return PTR_ERR(iomem);
ssi_private->ssi_phys = res->start;
+ if (ssi_private->soc->imx21regs) {
+ /* According to datasheet imx21-class SSI have less regs */
First of all, it would be "fewer regs", but even better would be to say
that c
Re: [PATCH 1/1] serial/uuc_uart: Set shutdown timeout to CONFIG_HZ independent 2ms
Alexander Stein wrote:
- schedule_timeout(2);
+ schedule_timeout(msecs_to_jiffies(2));
NACK.
So I don't remember why I wrote this code, but I don't think I was
expecting it to be 2ms. Instead, I think I just wanted it to be some
delay, but I believed that schedule_timeout(1) was too short or would be
"optimized" out somehow.
Note that right below this, I do:
if (qe_port->wait_closing) {
/* Wait a bit longer */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(qe_port->wait_closing);
}
And wait_closing is a number of jiffies, so I knew that
schedule_timeout() took jiffies as a parameter.
So I think I'm going to NACK this patch, since I believe I knew what I
was doing when I wrote it five years ago.
Re: [PATCH 1/1] serial/uuc_uart: Set shutdown timeout to CONFIG_HZ independent 2ms
Alexander Stein wrote: Okay, I was just wondering why the timeout is dependant on the timer tick. That didn't seem obvious to me. Rethinking about this, I would rather replace those lines with msleep instead. What's wrong with leaving it as-is? The code is five years old, and Freescale/NXP barely uses the QE any more. I don't have access to any hardware to test any changes you would propose.
Re: [PATCH] ASoC : fsl_ssi : Correct the condition to check AC97 mode
Andreas Schwab wrote: > + return !!(ssi_private->dai_fmt & SND_SOC_DAIFMT_AC97) == > + SND_SOC_DAIFMT_AC97; This is never true. I think the right parenthesis should be at the end of the expression.
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Grant Likely wrote: Okay, I've changed my mind. :-) I'll back off a bit from this extreme and call it: sound/soc/fsl/soc-of-simple.c That works for me. And please don't forget to CC: me on any discussion involving sound/soc/fsl. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
Jon Smirl wrote: > I'm just going to ignore 2.6.27 and wait for 2.6.28. 2.6.28 might have ASoC V2, or at least portions of it. You might want to just port your driver to ASoC V2 like I did and not worry about it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > Yes, please use something like clock-frequency or current-speed and do > the calculation. Ditto. I already wrote the code that does that for U-Boot, so all you need to do is port it. Although I'm curious, if U-Boot already programs the speed, why does the driver program it again? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: > I know but we still need an algorithm for MPC52xx and MPC82xx as well. That's true, but I still think hard-coding values of DFSR and FDR in the device tree is not a good way to do this. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
I2C node in device tree breaks old-style drivers
I'm trying to debug an I2C problem I've found in my old-style driver:
sound/soc/codecs/cs4270.c. My I2C probe function is working, but the I2C
subsystem cannot find my device. I know it's there, because U-Boot can probe it
just fine.
At first, I thought my problem was this:
static struct i2c_driver cs4270_i2c_driver = {
.driver = {
.name = "CS4270 I2C",
.owner = THIS_MODULE,
},
.id = I2C_DRIVERID_CS4270,
.attach_adapter = cs4270_i2c_attach,
.detach_client = cs4270_i2c_detach,
};
In a slightly older kernel (still 2.6.27), I had to change "CS4270 I2C" to
"cs4270" to get it to work. However, that change no longer makes a difference.
I turned on debugging and this is what I see:
i2c-core: driver [CS4270 I2C] registered
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x48
i2c-adapter i2c-0: master_xfer[0] W, addr=0x48, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x49
i2c-adapter i2c-0: master_xfer[0] W, addr=0x49, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4a
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4a, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4b
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4b, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4c
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4c, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4d
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4d, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4e
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4e, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4f
My device is at address 4F. The device tree defines a node for this device.
You can see it in arch/powerpc/boot/dts/mpc8610_hpcd.dts.
When I change the device tree so that it lists the device at an address other
than 4F, (e.g. "reg = <0x48>"), then my driver works.
So my conclusion is that specifying an I2C node in the device tree *requires*
that the driver be new-style. Is there any way we can fix this? I'm not going
to have time to update the CS4270 driver to a new-style interface before the
2.6.27 window closes.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C node in device tree breaks old-style drivers
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote: > Hi Timur, > >> So my conclusion is that specifying an I2C node in the device tree *requires* >> that the driver be new-style. Is there any way we can fix this? I'm not >> going >> to have time to update the CS4270 driver to a new-style interface before the >> 2.6.27 window closes. > > This conclusion is correct. One possible way to fix this is to add support for > blacklisting to drivers/of/base.c (untested): No need. I posted a patch to alsa-devel that makes the CS4270 a new-style I2C driver. I'd hate to think that my driver is the only I2C driver used on PowerPC systems that was outdated. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: > Aren't the tables in the manual there just to make it easy for a human > to pick out the line they want? For a computer you'd program the > formula that was used to create the tables. Actually, the tables in the manuals are just an example of what can be programmed. They don't cover all cases. The tables assume a specific value of DFSR. For 8xxx, you want to use AN2919 to figure out how to really program the device. The table I generated for U-Boot is based on the calculations outlined in AN2919. I debated trying to implement the actual algorithm, but decided that pre-calculating the values was better. The algorithm is very convoluted. > I agree that it took me half an hour to figure out the formula that > was needed to compute the i2s clocks, but once you figure out the > formula it solves all of the cases and no one needs to read the manual > any more. The i2c formula may even need a small loop which compares > different solutions looking for the smallest error term. But it's a > small space to search. My understanding is that the algorithm itself is different on 8xxx vs. 52xx. It might be possible to combine 5200A and 5200B into one table/algorithm, but I don't think you can combine it with the 8xxx table. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote:
> static const struct of_device_id mpc_i2c_of_match[] = {
> {.compatible = "fsl,mpc5200b-i2c", .data = fsl_i2c_mpc5200b_set_freq, },
> {.compatible = "fsl,mpc5200-i2c", .data = fsl_i2c_mpc5200_set_freq, },
> {.compatible = "fsl,mpc8260-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8349-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8540-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8543-i2c", .data =
> fsl_i2c_mpc8xxx_div2_set_freq, },
> {.compatible = "fsl,mpc8544-i2c", .data =
> fsl_i2c_mpc8xxx_div3_set_freq, },
So we need to update this table every time there's a new SOC? All 83xx, 85xx,
and 86xx SOCs use the same table. I'd prefer an implementation that does need a
specific entry for each variant of 8[356]xx.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: > We could add a property "source-clock-divider = <2/3>" if it's needed!? How about we just get U-Boot to put the core frequency in the device tree? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote: > On Thu, Jul 31, 2008 at 12:07 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> > wrote: >> We could add a property "source-clock-divider = <2/3>" if it's needed!? > > fsl,source-clock-divider > > But, yes, this is a good solution (assuming that it is a board or SoC > characteristic, and not just a choice that the driver has the option > of making on it's own). I was going to suggest the actual clock frequency of the I2C device. It would be value of gd->i2c1_clk or gd->i2c2_clk from U-Boot. The actual divider value is meaningless. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
