Re: [PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
Oh, I thought we agreed that you take it via powerpc. I still think this is the best solution. I threatened to do that :-) I don't remember you replying, did I miss it ? It is here: http://thread.gmane.org/gmane.linux.drivers.i2c/20762/focus=21099 If you are ok with the driver and are happy for me to take it, please send an Ack. Happy is not the correct word, but let's just go over with it. Maybe like this: Acked-by: Wolfram Sang w...@the-dreams.de (I2C part, excluding the bindings) From a binding perspective, it's just a piece of additional info that the firmware provides for convenience. I do understand the use case. I even agree it makes sense to have something like this. It is just that I'd prefer a generic, widely acknowledged solution, with consensus where it belongs and how it should be named. Not a custom solution which, frankly, feels forced on me by time pressure I have nothing to do with. So, not happy here, but also not looking for drama. Let's move on... signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
On Tue, 2014-12-09 at 09:54 +0100, Wolfram Sang wrote: Oh, I thought we agreed that you take it via powerpc. I still think this is the best solution. I threatened to do that :-) I don't remember you replying, did I miss it ? It is here: http://thread.gmane.org/gmane.linux.drivers.i2c/20762/focus=21099 Weird, it never made it to my mbox... anyway: I did not invent DT bindings. No I did :) Or rather Mitch did with OF and I contributed heavily at slapping it onto everbody's face :) Then I let Grant run with it and deal with the carnage... but as you can imagine, I feel like whatever rule I made for others don't apply to me :) I did not invent that DT is/should be a hardware description. This is the basic idea but it's flexible. It is in essence a description of the environment, which is essentially the HW but there is no taboo about adding various ancilliary pieces of informations that one deems useful, especially if they are prefixed by a vendor prefix to avoid collision with well defined properties. I think we ended up being fairly strict about the rules initially to try to rein in the crowd of ARM embedded folks who really went all over the place but like every rule, it's meant to be broken (hear the french guy talking ...). For me, it is a burden that I (as a subsystem maintainer for mainly drivers) have to prevent people from using DT ? for software configuration (some people use it as an 1:1 mapping for platform data even.) Well, yes and no... for example, it's perfectly legit to have a node representing a UART, have the firmware slap into it the default expected baud rate as a property (or whatever it has configured it to be) which makes it then a reasonable default for the kernel to use. Generally speaking there is nothing fundamentally wrong about having configuration information in the device-tree, but it has to be clearly identifiable as such. The description of the HW in my world at least also implies how that HW is meant to be configured for a given platform. Since there are no guidelines (probably there can't be), I developed a set of rules out of experience and when those don't match I ask for help. Having a different set of rules for powerpc/arm/... (or server/embedded for that matter) will increase this burden a lot. People will come and say But they did it as well... The basic rule is does it make sense ?. Really. Apply your jugement based on your experience as to whether something is a reasonable comprimise or not and whether it will turn into a big mess in the long run or, on the contrary, is a perfectly fine ad-hoc solution for a given setup. It's getting quite tempting to just throw that driver into powerpc.git Maybe this is the easiest. Just make sure that MAINTAINERS also point this driver to you or PowerNV maintainers. And no Ack from me, please. Then, I can always say I dunno if people start asking questions. :) Technically I need your ack if we are to follow the process for Linux upstreaming. I doubt Linux will holler if I just put it in the tree but I'd rather follow the process if possible. And I don't give a flying crap about what random ARM SOC vendor thinks of my powerpc FW interface for a powerpc unique FW interface. But you are not alone here. If you open the box for giving busses a configurable name, I can see other people (without FW) wanting this, too. So, this discussion will come anyhow IMO. Right and I personally don't see a problem with that ... what's fundamentally wrong with letting the platform description (ie,. the DT) specify reasonable names for i2c busses ? It has pretty much no impact on drivers nowadays but means things are easier to figure out/locate for users/admin/developers and eases diagnostics. If you are ok with the driver and are happy for me to take it, please send an Ack. Happy is not the correct word, but let's just go over with it. Maybe like this: Acked-by: Wolfram Sang w...@the-dreams.de (I2C part, excluding the bindings) Forget about the binding mess, Olof reminded me that the result of one of the recent KS was that the bindings no longer needed approval, and are to be sent to the list purely for informational purposes, otherwise the process is a mess. We have to provide at least some trust here, and we can reject the driver if we think the binding is really way too gross. From a binding perspective, it's just a piece of additional info that the firmware provides for convenience. I do understand the use case. I even agree it makes sense to have something like this. It is just that I'd prefer a generic, widely acknowledged solution, with consensus where it belongs and how it should be named. Not a custom solution which, frankly, feels forced on me by time pressure I have nothing to do with. So, not happy here, but also not looking for drama. Let's move on... Adding a generic binding for i2c controllers to name their respective busses sounds like a laudable idea, and
Re: [PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote:
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device infrastructure to probe the busses
on the platform and registers them with the i2c driver framework.
Wolfram, what are you remaining objections here ? We need that in
distros ASAP ...
I still maintain that it's not reasonable to hold driver for the
additions of multi-byte smbus offsets. This is a new feature that will
require changes to a number of existing bus and device drivers, so a
very pervasive change, and which will be visible to user space, which
means that drivers will need to continue supporting the old way at
least for a while anyway...
Ben.
Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2 - v3:
- Added the device tree binding documentation for the driver.
- Sorted the ordering of this new driver added in Makefile.
- Removed populating the superfluous .owner field in 'struct driver'.
Documentation/devicetree/bindings/i2c/i2c-opal.txt | 37 +++
arch/powerpc/include/asm/opal.h| 29 ++
arch/powerpc/platforms/powernv/opal-wrappers.S |1
arch/powerpc/platforms/powernv/opal.c | 11 +
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile|1
drivers/i2c/busses/i2c-opal.c | 294
7 files changed, 384 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-opal.txt
create mode 100644 drivers/i2c/busses/i2c-opal.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-opal.txt
b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
new file mode 100644
index 000..12bc614
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
@@ -0,0 +1,37 @@
+Device-tree bindings for I2C OPAL driver
+
+
+Most of the device node and properties layout is specific to the firmware and
+used by the firmware itself for configuring the port. From the linux
+perspective, the properties of use are ibm,port-name and ibm,opal-id.
+
+Required properties:
+
+- reg: Port-id within a given master
+- compatible: must be ibm,opal-i2c
+- ibm,opal-id: Refers to a specific bus and used to identify it when calling
+the relevant OPAL functions.
+- bus-frequency: Operating frequency of the i2c bus (in HZ). Informational
for
+ linux, used by the FW though.
+
+Optional properties:
+- ibm,port-name: Firmware provides this name that uniquely identifies the i2c
+ port.
+
+The node contains a number of other properties that are used by the FW itself
+and depend on the specific hardware implementation. The example below depicts
+a P8 on-chip bus.
+
+Example:
+
+i2c-bus@0 {
+ reg = 0x0;
+ bus-frequency = 0x61a80;
+ compatible = ibm,power8-i2c-port, ibm,opal-i2c;
+ ibm,opal-id = 0x1;
+ ibm,port-name = p8__e1p0;
+ #address-cells = 0x1;
+ phandle = 0x1006;
+ #size-cells = 0x0;
+ linux,phandle = 0x1006;
+};
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9124b0e..537807b 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -56,6 +56,14 @@ struct opal_sg_list {
#define OPAL_HARDWARE_FROZEN -13
#define OPAL_WRONG_STATE -14
#define OPAL_ASYNC_COMPLETION-15
+#define OPAL_I2C_TIMEOUT -17
+#define OPAL_I2C_INVALID_CMD -18
+#define OPAL_I2C_LBUS_PARITY -19
+#define OPAL_I2C_BKEND_OVERRUN -20
+#define OPAL_I2C_BKEND_ACCESS-21
+#define OPAL_I2C_ARBT_LOST -22
+#define OPAL_I2C_NACK_RCVD -23
+#define OPAL_I2C_STOP_ERR-24
/* API Tokens (in r0) */
#define OPAL_INVALID_CALL-1
@@ -154,6 +162,7 @@ struct opal_sg_list {
#define OPAL_HANDLE_HMI 98
#define OPAL_REGISTER_DUMP_REGION101
#define OPAL_UNREGISTER_DUMP_REGION 102
+#define OPAL_I2C_REQUEST 109
#ifndef __ASSEMBLY__
@@ -801,6 +810,24 @@ typedef struct oppanel_line {
uint64_tline_len;
} oppanel_line_t;
+/* OPAL I2C request */
+struct opal_i2c_request {
+ uint8_t type;
+#define OPAL_I2C_RAW_READ0
+#define OPAL_I2C_RAW_WRITE 1
+#define OPAL_I2C_SM_READ 2
+#define OPAL_I2C_SM_WRITE3
+ uint8_t flags;
+#define OPAL_I2C_ADDR_10 0x01/* Not supported yet */
+ uint8_t subaddr_sz; /* Max 4 */
+ uint8_t reserved;
+ __be16 addr;/* 7 or 10 bit address */
+ __be16 reserved2;
+ __be32 subaddr; /* Sub-address if any */
+ __be32 size;/* Data size
Re: [PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
On Tue, Dec 09, 2014 at 07:13:15AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote: The patch exposes the available i2c busses on the PowerNV platform to the kernel and implements the bus driver to support i2c and smbus commands. The driver uses the platform device infrastructure to probe the busses on the platform and registers them with the i2c driver framework. Wolfram, what are you remaining objections here ? We need that in distros ASAP ... Oh, I thought we agreed that you take it via powerpc. I still think this is the best solution. I still maintain that it's not reasonable to hold driver for the additions of multi-byte smbus offsets. This is a new feature that will require changes to a number of existing bus and device drivers, so a very pervasive change, and which will be visible to user space, which means that drivers will need to continue supporting the old way at least for a while anyway... Yeah, I agree on that. I am still unsure about the port-name binding, but well, if it is needed to fit your PowerNV scheme... Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- v2 - v3: - Added the device tree binding documentation for the driver. - Sorted the ordering of this new driver added in Makefile. - Removed populating the superfluous .owner field in 'struct driver'. Thanks for the updates! signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
On Mon, 2014-12-08 at 21:55 +0100, Wolfram Sang wrote: On Tue, Dec 09, 2014 at 07:13:15AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote: The patch exposes the available i2c busses on the PowerNV platform to the kernel and implements the bus driver to support i2c and smbus commands. The driver uses the platform device infrastructure to probe the busses on the platform and registers them with the i2c driver framework. Wolfram, what are you remaining objections here ? We need that in distros ASAP ... Oh, I thought we agreed that you take it via powerpc. I still think this is the best solution. I threatened to do that :-) I don't remember you replying, did I miss it ? If you are ok with the driver and are happy for me to take it, please send an Ack. I still maintain that it's not reasonable to hold driver for the additions of multi-byte smbus offsets. This is a new feature that will require changes to a number of existing bus and device drivers, so a very pervasive change, and which will be visible to user space, which means that drivers will need to continue supporting the old way at least for a while anyway... Yeah, I agree on that. I am still unsure about the port-name binding, but well, if it is needed to fit your PowerNV scheme... From a binding perspective, it's just a piece of additional info that the firmware provides for convenience. That we use it as the i2c port name in Linux makes sense, it means that when listing the i2c ports, it's immediately clear to the user which is which, it's not used functionally by any driver or piece of code, but it's handy for people doing things like manufacturing of machines, to know what bus to poke to program a VPD EEPROM or test if a chip responds for example. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] i2c: Driver to expose PowerNV platform i2c busses
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device infrastructure to probe the busses
on the platform and registers them with the i2c driver framework.
Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2 - v3:
- Added the device tree binding documentation for the driver.
- Sorted the ordering of this new driver added in Makefile.
- Removed populating the superfluous .owner field in 'struct driver'.
Documentation/devicetree/bindings/i2c/i2c-opal.txt | 37 +++
arch/powerpc/include/asm/opal.h| 29 ++
arch/powerpc/platforms/powernv/opal-wrappers.S |1
arch/powerpc/platforms/powernv/opal.c | 11 +
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile|1
drivers/i2c/busses/i2c-opal.c | 294
7 files changed, 384 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-opal.txt
create mode 100644 drivers/i2c/busses/i2c-opal.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-opal.txt
b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
new file mode 100644
index 000..12bc614
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-opal.txt
@@ -0,0 +1,37 @@
+Device-tree bindings for I2C OPAL driver
+
+
+Most of the device node and properties layout is specific to the firmware and
+used by the firmware itself for configuring the port. From the linux
+perspective, the properties of use are ibm,port-name and ibm,opal-id.
+
+Required properties:
+
+- reg: Port-id within a given master
+- compatible: must be ibm,opal-i2c
+- ibm,opal-id: Refers to a specific bus and used to identify it when calling
+ the relevant OPAL functions.
+- bus-frequency: Operating frequency of the i2c bus (in HZ). Informational for
+linux, used by the FW though.
+
+Optional properties:
+- ibm,port-name: Firmware provides this name that uniquely identifies the i2c
+port.
+
+The node contains a number of other properties that are used by the FW itself
+and depend on the specific hardware implementation. The example below depicts
+a P8 on-chip bus.
+
+Example:
+
+i2c-bus@0 {
+ reg = 0x0;
+ bus-frequency = 0x61a80;
+ compatible = ibm,power8-i2c-port, ibm,opal-i2c;
+ ibm,opal-id = 0x1;
+ ibm,port-name = p8__e1p0;
+ #address-cells = 0x1;
+ phandle = 0x1006;
+ #size-cells = 0x0;
+ linux,phandle = 0x1006;
+};
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9124b0e..537807b 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -56,6 +56,14 @@ struct opal_sg_list {
#define OPAL_HARDWARE_FROZEN -13
#define OPAL_WRONG_STATE -14
#define OPAL_ASYNC_COMPLETION -15
+#define OPAL_I2C_TIMEOUT -17
+#define OPAL_I2C_INVALID_CMD -18
+#define OPAL_I2C_LBUS_PARITY -19
+#define OPAL_I2C_BKEND_OVERRUN -20
+#define OPAL_I2C_BKEND_ACCESS -21
+#define OPAL_I2C_ARBT_LOST -22
+#define OPAL_I2C_NACK_RCVD -23
+#define OPAL_I2C_STOP_ERR -24
/* API Tokens (in r0) */
#define OPAL_INVALID_CALL -1
@@ -154,6 +162,7 @@ struct opal_sg_list {
#define OPAL_HANDLE_HMI98
#define OPAL_REGISTER_DUMP_REGION 101
#define OPAL_UNREGISTER_DUMP_REGION102
+#define OPAL_I2C_REQUEST 109
#ifndef __ASSEMBLY__
@@ -801,6 +810,24 @@ typedef struct oppanel_line {
uint64_tline_len;
} oppanel_line_t;
+/* OPAL I2C request */
+struct opal_i2c_request {
+ uint8_t type;
+#define OPAL_I2C_RAW_READ 0
+#define OPAL_I2C_RAW_WRITE 1
+#define OPAL_I2C_SM_READ 2
+#define OPAL_I2C_SM_WRITE 3
+ uint8_t flags;
+#define OPAL_I2C_ADDR_10 0x01/* Not supported yet */
+ uint8_t subaddr_sz; /* Max 4 */
+ uint8_t reserved;
+ __be16 addr;/* 7 or 10 bit address */
+ __be16 reserved2;
+ __be32 subaddr; /* Sub-address if any */
+ __be32 size;/* Data size */
+ __be64 buffer_ra; /* Buffer real address */
+};
+
/* /sys/firmware/opal */
extern struct kobject *opal_kobj;
@@ -963,6 +990,8 @@ int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
+int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
+struct opal_i2c_request *oreq);
/* Internal functions */
extern int
