Re: [PATCH] i2c: i2c-sh_mobile device tree support
On Fri, Mar 30, 2012 at 05:44:02PM +0900, Magnus Damm wrote:
+static const struct of_device_id sh_mobile_i2c_dt_ids[] __devinitconst = {
+ { .compatible = renesas,rmobile-iic, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sh_mobile_i2c_dt_ids);
+
Given that this block predates R-Mobile, using the rmobile naming here is
pretty dubious. I suppose you can have it as an alias, though.
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-sh_mobile device tree support
On Fri, Mar 30, 2012 at 05:53:35PM +0900, Magnus Damm wrote:
On Fri, Mar 30, 2012 at 5:47 PM, Paul Mundt let...@linux-sh.org wrote:
On Fri, Mar 30, 2012 at 05:44:02PM +0900, Magnus Damm wrote:
+static const struct of_device_id sh_mobile_i2c_dt_ids[] __devinitconst = {
+ ? ? { .compatible = renesas,rmobile-iic, },
+ ? ? {},
+};
+MODULE_DEVICE_TABLE(of, sh_mobile_i2c_dt_ids);
+
Given that this block predates R-Mobile, using the rmobile naming here is
pretty dubious. I suppose you can have it as an alias, though.
Sure, but creating new code based an old naming conventions seem rather
odd too.
Devices should be named what they are, not what the marketing people tell
you they should be. Retroactively attempting to label parts that pre-date
rmobile as being rmobile-related is non-sensical. The driver itself
you'll note is not called i2c-rmobile for precisely this reason.
Furthermore, there are also ARM-based SH-Mobile parts that pre-date the
R-Mobile line that also use this driver, so it's hardly an architecture
issue.
Of course, if you think it is cramping your SH device tree style then
we can easily add a renesas-shmobile-iic entry as well.
I obviously don't mind if you wish to use the rmobile naming convention
going forward, as the new parts have obviously dropped with the shmobile
naming convention, and it's likely you'll even be able to infer different
capabilities between rmobile vs shmobile. That's not sufficient cause to
prefer one over the other though, so you're still going to have to keep
things balanced. Simply having two aliases seems to me to be the easiest
solution.
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: i2c-riic: add support for Renesas RIIC
On Mon, Jul 11, 2011 at 08:03:35AM +0200, Jean Delvare wrote: On Mon, 11 Jul 2011 14:52:21 +0900, Paul Mundt wrote: On Fri, Jul 01, 2011 at 10:00:42AM +0900, Yoshihiro Shimoda wrote: This driver supports the RIIC module. The SH7757 has it. The driver doesn't use any IRQ handler. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- drivers/i2c/busses/Kconfig|9 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-riic.c | 589 + include/linux/i2c/riic.h | 29 ++ 4 files changed, 628 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-riic.c create mode 100644 include/linux/i2c/riic.h Ping? Embedded platform - ping Ben, not me. It was addressed to Ben and there has been no response. Ben has also been included in the Cc for the ping in question. If there continues to be no response, how exactly do you propose making progress on this? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: i2c-riic: add support for Renesas RIIC
On Fri, Jul 01, 2011 at 10:00:42AM +0900, Yoshihiro Shimoda wrote: This driver supports the RIIC module. The SH7757 has it. The driver doesn't use any IRQ handler. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- drivers/i2c/busses/Kconfig|9 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-riic.c | 589 + include/linux/i2c/riic.h | 29 ++ 4 files changed, 628 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-riic.c create mode 100644 include/linux/i2c/riic.h Ping? diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 646068e..e057344 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -687,6 +687,15 @@ config I2C_EG20T ML7213/ML7223 is companion chip for Intel Atom E6xx series. ML7213/ML7223 is completely compatible for Intel EG20T PCH. +config I2C_RIIC + tristate Renesas RIIC controller + depends on SUPERH + help + This driver supports the RIIC module of the Renesas SH7757. + + This driver can also be built as a module. If so, the module + will be called i2c-riic. + comment External I2C/SMBus adapter drivers config I2C_DIOLAN_U2C diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index e6cf294..e8c9b1f 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -66,6 +66,7 @@ obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o obj-$(CONFIG_I2C_XILINX) += i2c-xiic.o obj-$(CONFIG_I2C_EG20T) += i2c-eg20t.o +obj-$(CONFIG_I2C_RIIC) += i2c-riic.o # External I2C/SMBus adapter drivers obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c new file mode 100644 index 000..dcc183b --- /dev/null +++ b/drivers/i2c/busses/i2c-riic.c @@ -0,0 +1,589 @@ +/* + * RIIC bus driver + * + * Copyright (C) 2011 Renesas Solutions Corp. + * + * Based on i2c-sh_mobile.c + * Portion Copyright (C) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + */ + +#include linux/kernel.h +#include linux/platform_device.h +#include linux/interrupt.h +#include linux/i2c.h +#include linux/i2c/riic.h +#include linux/io.h +#include linux/timer.h +#include linux/delay.h +#include linux/slab.h + +#define RIIC_ICCR1 0x00 +#define RIIC_ICCR2 0x01 +#define RIIC_ICMR1 0x02 +#define RIIC_ICMR2 0x03 +#define RIIC_ICMR3 0x04 +#define RIIC_ICFER 0x05 +#define RIIC_ICSER 0x06 +#define RIIC_ICIER 0x07 +#define RIIC_ICSR1 0x08 +#define RIIC_ICSR2 0x09 +#define RIIC_SARL0 0x0a +#define RIIC_SARU0 0x0b +#define RIIC_SARL1 0x0c +#define RIIC_SARU1 0x0d +#define RIIC_SARL2 0x0e +#define RIIC_SARU2 0x0f +#define RIIC_ICBRL 0x10 +#define RIIC_ICBRH 0x11 +#define RIIC_ICDRT 0x12 +#define RIIC_ICDRR 0x13 + +/* ICCR1 */ +#define ICCR1_ICE0x80 +#define ICCR1_IICRST 0x40 +#define ICCR1_CLO0x20 +#define ICCR1_SOWP 0x10 +#define ICCR1_SCLO 0x08 +#define ICCR1_SDAO 0x04 +#define ICCR1_SCLI 0x02 +#define ICCR1_SDAI 0x01 + +/* ICCR2 */ +#define ICCR2_BBSY 0x80 +#define ICCR2_MST0x40 +#define ICCR2_TRS0x20 +#define ICCR2_SP 0x08 +#define ICCR2_RS 0x04 +#define ICCR2_ST 0x02 + +/* ICMR1 */ +#define ICMR1_MTWP 0x80 +#define ICMR1_CKS_MASK 0x70 +#define ICMR1_BCWP 0x08 +#define ICMR1_BC_MASK0x07 + +#define ICMR1_CKS(_x)((_x 4) ICMR1_CKS_MASK) +#define ICMR1_BC(_x) (_x ICMR1_BC_MASK) + +/* ICMR2 */ +#define ICMR2_DLCS 0x80 +#define ICMR2_SDDL_MASK 0x70 +#define ICMR2_TMOH 0x04 +#define ICMR2_TMOL 0x02 +#define ICMR2_TMOS 0x01 + +/* ICMR3 */ +#define ICMR3_SMBS 0x80 +#define ICMR3_WAIT 0x40 +#define ICMR3_RDRFS 0x20 +#define ICMR3_ACKWP 0x10 +#define ICMR3_ACKBT 0x08 +#define ICMR3_ACKBR 0x04 +#define ICMR3_NF_MASK0x03 + +/* ICFER */ +#define ICFER_FMPE 0x80 +#define ICFER_SCLE 0x40 +#define ICFER_NFE0x20 +#define ICFER_NACKE 0x10 +#define ICFER_SALE 0x08 +#define ICFER_NALE 0x04 +#define ICFER_MALE 0x02 +#define ICFER_TMOE 0x01 + +/* ICSER */
Re: [PATCH] i2c: i2c-sh_mobile bus speed platform data
On Thu, Apr 28, 2011 at 10:18:01AM +0900, Simon Horman wrote: On Thu, Apr 28, 2011 at 10:06:38AM +0900, Magnus Damm wrote: On Thu, Apr 28, 2011 at 7:14 AM, Simon Horman ho...@verge.net.au wrote: I believe that on the sh73a0 and so far only the sh73a0 denom needs to be doubled. Uhm, I don't think this patch is specific to any SoC type. It may of course be used on sh73a0 to adjust the denom value, but setting the I2C bus speed is something that can be used on any SoC. So I'd say that this is a fairly generic feature. I'm just saying that that I've observed the value being doubled for sh73a0. The general rule of thumb is that whatever unusual behaviour is observed in the latest CPU we will see become the standard for future ones. Abstracting the denom value seems reasonable as a cautionary measure, and it does do the NORMAL_SPEED as a default fallback so there is no adverse impact for normalized platforms. This really should be going in to include/linux/i2c/ or so though, no need to dump these tiny stubs in to include/linux/ directly. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sh: fix SD / MMC configuration dependencies on ecovec
On Fri, Apr 15, 2011 at 08:03:17PM +0200, Guennadi Liakhovetski wrote: Update CONFIG_MMC_TMIO to the new CONFIG_MMC_SDHI symbol and fix MMCIF to also function in modular builds for ecovec. On Fri, Apr 15, 2011 at 08:04:12PM +0200, Guennadi Liakhovetski wrote: arch/sh/configs/ecovec24_defconfig |2 +- arch/sh/configs/sh7757lcr_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) On Fri, Apr 15, 2011 at 08:17:34PM +0200, Guennadi Liakhovetski wrote: This patch enables FSI driver autoloading on sh-mobile systems. On Fri, Apr 15, 2011 at 08:18:57PM +0200, Guennadi Liakhovetski wrote: This patch enables I2C driver autoloading on sh-mobile systems. All applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: tca6416-keypad: Change to module_init()
On Tue, Mar 22, 2011 at 02:28:55PM +, Mark Brown wrote: On Tue, Mar 22, 2011 at 11:26:19PM +0900, Magnus Damm wrote: The tca6416 driver makes use of the I2C bus for chatting with the actual hardware device. Without this patch both the I2C bus driver and the tca6416 driver are initialized at the subsys_initcall() level. This may lead to problems with the tca6416 driver being initialized before the I2C bus driver. While this change seems reasonable I'm curious what the problems caused by out of order registration are? I'm also curious as to why link order isn't a sufficient gaurantee like it is for everyone else? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: tca6416-keypad: Change to module_init()
On Wed, Mar 23, 2011 at 12:22:05AM +0900, Magnus Damm wrote: On Tue, Mar 22, 2011 at 11:33 PM, Paul Mundt let...@linux-sh.org wrote: On Tue, Mar 22, 2011 at 02:28:55PM +, Mark Brown wrote: On Tue, Mar 22, 2011 at 11:26:19PM +0900, Magnus Damm wrote: The tca6416 driver makes use of the I2C bus for chatting with the actual hardware device. Without this patch both the I2C bus driver and the tca6416 driver are initialized at the subsys_initcall() level. This may lead to problems with the tca6416 driver being initialized before the I2C bus driver. While this change seems reasonable I'm curious what the problems caused by out of order registration are? I'm also curious as to why link order isn't a sufficient gaurantee like it is for everyone else? I believe all other i2c keyboard drivers use module_init(). We do not change initcall ordering around unless there is a reason to do so, as it's assumed that a given initcall has been chosen for a reason. You have hit upon a bug or at least something timing related causing you a delay and so have elected to push it down a level. That is of course fine, but none of that is anywhere in your commit text leaving us to try and figure out what exactly the point of this exercise is. Usually because everyone else is doing it and another driver is not, there's a reason for that driver doing things differently. There are certainly enough cases where initcall and link ordering is strongly ordered for a reason that cosmetic/janitorial fixes are best rejected out of hand. You had a reason, great. Next time put it in your commit text. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: tca6416-keypad: Change to module_init()
On Wed, Mar 23, 2011 at 12:43:54AM +0900, Magnus Damm wrote: On Wed, Mar 23, 2011 at 12:32 AM, Paul Mundt let...@linux-sh.org wrote: On Wed, Mar 23, 2011 at 12:22:05AM +0900, Magnus Damm wrote: I believe all other i2c keyboard drivers use module_init(). We do not change initcall ordering around unless there is a reason to do so, as it's assumed that a given initcall has been chosen for a reason. Yes, obviously this driver is special and all other keypad drivers are wrong. I'm not sure why you're purposely trying to be dense. I was explaining why it's not uncommon to find drivers using subsys_initcall for various non-obvious reasons and why blindly changing them without valid rationale generally causes more trouble than it prevents. In the case of a keypad driver it's unlikely to matter, but someone may still have had a reason for doing so. Given that your patch is fixing a problem, this is what should be reflected in your commit text, not some vague hand-waving about what everyone else is doing or what could hypothetically lead to problems. It would be interesting to hear why subsys_initcall() was put there in the first place. In this case I would suspect general indifference or simply copying other drivers. I2C is a bit of a tricky case with regards to ordering in general, but at least input devices are relatively straightforward. The keypad driver tries to use the I2C bus before the I2C bus driver is initialized. Isn't that a pretty good reason to change the initcall order? Yes, and that part is also not mentioned anywhere in your commit text. Starting to see a pattern? You had a reason, great. Next time put it in your commit text. Whatever. Let me know which lines you'd like to add and I'll send a V2. I don't think it's too much to ask that you write a commit text that actually mentions what problem you are experiencing and fixing. I also don't know why this needs to be pointed out. One shouldn't have to work for an explanation of what purpose your patch serves when you're the one trying to get it merged. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sh: i2c-sh7760: Replase from ctrl_* to __raw_*
On Tue, Oct 26, 2010 at 07:43:07AM +0100, Ben Dooks wrote: On Tue, Oct 26, 2010 at 01:02:03PM +0900, Paul Mundt wrote: On Tue, Oct 26, 2010 at 09:08:12AM +0900, Nobuhiro Iwamatsu wrote: 2010/10/25 Ben Dooks ben-...@fluff.org: On Mon, Oct 25, 2010 at 08:13:25PM +0900, Paul Mundt wrote: On Mon, Oct 25, 2010 at 11:47:18AM +0100, Ben Dooks wrote: On Mon, Oct 25, 2010 at 10:58:35AM +0900, Paul Mundt wrote: On Sat, Oct 23, 2010 at 07:07:00AM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org Applied, thanks. Hi, can you see my comments about the copy of this posted below about ioremap() and use or __raw accessors? No? At least it never made it to the list. Do you have a pointer handy? http://marc.info/?l=linux-i2cm=128797023230600w=2 Sorry, this is my mistake. On Sun, Oct 24, 2010 at 05:37:46PM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Given iobase is ioremap() returned, there should be an explicit reason for using __raw_xxx() instead of read/writel(). Based on what, exactly? The CPU in question is quite content with the weak ordering provided by __raw_xxx(), anything more is unecessary. generally, readX,writeX or iowriteX,ioreadX are the functions that should be used on ioremap()d memory. It may not be a hard rule, but it is how it is supposed to be done. Nonsense. There are plenty of cases in the kernel that use __raw_xxx() on ioremapped memory and have been since before ioread/writeX even existed. Whether to use read/writeX or the __raw versions has always been up to the developer, and if the ordering issues don't factor in then there is simply no reason to bother using read/writeX. If you wish to do a kernel-wide audit and convert all __raw_xxx users on ioremapped memory over you are certainly welcome to try. Inserting extra memory barriers for strong ordering where it isn't needed however is completely pointless. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sh: i2c-sh7760: Replase from ctrl_* to __raw_*
On Mon, Oct 25, 2010 at 11:47:18AM +0100, Ben Dooks wrote: On Mon, Oct 25, 2010 at 10:58:35AM +0900, Paul Mundt wrote: On Sat, Oct 23, 2010 at 07:07:00AM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org Applied, thanks. Hi, can you see my comments about the copy of this posted below about ioremap() and use or __raw accessors? No? At least it never made it to the list. Do you have a pointer handy? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sh: i2c-sh7760: Replase from ctrl_* to __raw_*
On Tue, Oct 26, 2010 at 09:08:12AM +0900, Nobuhiro Iwamatsu wrote: 2010/10/25 Ben Dooks ben-...@fluff.org: On Mon, Oct 25, 2010 at 08:13:25PM +0900, Paul Mundt wrote: On Mon, Oct 25, 2010 at 11:47:18AM +0100, Ben Dooks wrote: On Mon, Oct 25, 2010 at 10:58:35AM +0900, Paul Mundt wrote: On Sat, Oct 23, 2010 at 07:07:00AM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org Applied, thanks. Hi, can you see my comments about the copy of this posted below about ioremap() and use or __raw accessors? No? At least it never made it to the list. Do you have a pointer handy? http://marc.info/?l=linux-i2cm=128797023230600w=2 Sorry, this is my mistake. On Sun, Oct 24, 2010 at 05:37:46PM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Given iobase is ioremap() returned, there should be an explicit reason for using __raw_xxx() instead of read/writel(). Based on what, exactly? The CPU in question is quite content with the weak ordering provided by __raw_xxx(), anything more is unecessary. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sh: i2c-sh7760: Replase from ctrl_* to __raw_*
On Sat, Oct 23, 2010 at 07:07:00AM +0900, Nobuhiro Iwamatsu wrote: ctrl_* is deprecated. We should to use __raw_*. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: idr_get_new_exact ?
On Mon, Sep 20, 2010 at 11:26:47PM +0200, Tejun Heo wrote: Hello, On 09/20/2010 10:35 PM, Roland Dreier wrote: Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. I agree. Wouldn't those users better off simply using radix tree? It could go either way. I was about to write the same function when playing with it for IRQ mapping, the idea being to propagate the initial tree with sparse static vectors and then switch over to dynamic IDs for virtual IRQ creation. I ended up going with a radix tree for other reasons, though. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: mach-shmobile: add INTCS macros
On Thu, Mar 11, 2010 at 02:30:30PM +0900, Magnus Damm wrote: Add SH-Mobile ARM INTCS macros for the INTCS controller. On Thu, Mar 11, 2010 at 03:52:33PM +0900, Magnus Damm wrote: Add support for the sh7367 INTCS interrupt controller. INTCS is the interrupt controller for the sh7367 SuperH processor core. It is tied into the INTCA interrupt controller which interfaces to the ARM processor. INTCS support is implemented using a new INTC table together with a chained interrupt handler that ties into the already supported INTCA controller. On Thu, Mar 11, 2010 at 07:05:26PM +0900, Magnus Damm wrote: i2c: i2c-sh_mobile update for SH-Mobile ARM [PATCH 01/03] i2c: i2c-sh_mobile register access code break out [PATCH 02/03] i2c: i2c-sh_mobile support for new ICIC bits [PATCH 03/03] i2c: i2c-sh_mobile kconfig update for SH-Mobile ARM These patches add support for a newer version of the IIC block to the i2c-sh_mobile and enables the driver on SH-Mobile ARM. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c/highlander: remover superflous variable
On Tue, Feb 02, 2010 at 01:17:43PM +0100, Wolfram Sang wrote: When cppcheck found this flaw [./i2c/busses/i2c-highlander.c:284]: (style) Warning - using char variable in bit operation it was noted that the 'read'-variable could just be removed as read_write can only be 0 or 1 anyhow. So, we remove the flaw by simplifying the code. Reported-by: d binderman dcb...@hotmail.com Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Paul Mundt let...@linux-sh.org Cc: Jean Delvare kh...@linux-fr.org Cc: Ben Dooks ben-li...@fluff.org Fine with me. Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: Renesas SDK7786 FPGA I2C/SMBus support.
This adds a simple driver for the SMBus interfaces in the SDK7786 FPGA.
At present this includes 2 identically implemented blocks, one for
wrangling control from the CPU I2C for the RTC, and a secondary one for
PCI Express. As this will vary across FPGA versions, we use a platform
device abstraction and leave it to the board code (which already has FPGA
versioning information available to it) to figure out what it wants.
These are fairly simple controllers, only supporting control and data
registers, with no IRQ to speak of.
Signed-off-by: Paul Mundt let...@linux-sh.org
---
Note that the board support for this is in my tree for 2.6.34, so I can
carry this patch there as well once folks are happy with it.
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile |1
drivers/i2c/busses/i2c-sdk7786.c | 163 +++
3 files changed, 171 insertions(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5f318ce..5cdad4e 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -509,6 +509,13 @@ config I2C_S6000
To compile this driver as a module, choose M here. The module
will be called i2c-s6000.
+config I2C_SDK7786
+ tristate Renesas SDK7786 FPGA SMBus interface
+ depends on SH_SDK7786
+ help
+ This driver supports the various SMBus controllers in the
+ SDK7786 FPGA.
+
config I2C_SH7760
tristate Renesas SH7760 I2C Controller
depends on CPU_SUBTYPE_SH7760
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 302c551..6162f22 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o
obj-$(CONFIG_I2C_S6000)+= i2c-s6000.o
+obj-$(CONFIG_I2C_SDK7786) += i2c-sdk7786.o
obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o
obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
diff --git a/drivers/i2c/busses/i2c-sdk7786.c b/drivers/i2c/busses/i2c-sdk7786.c
new file mode 100644
index 000..c37a29d
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sdk7786.c
@@ -0,0 +1,163 @@
+/*
+ * Renesas SDK7786 FPGA I2C/SMBus support.
+ *
+ * Copyright (C) 2010 Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main directory
+ * of this archive for more details.
+ */
+#include linux/init.h
+#include linux/io.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/platform_device.h
+
+#define I2CCR 0x
+#define I2CDR 0x0010
+
+struct sdk7786_i2c_dev {
+ void __iomem*base;
+ struct i2c_adapter adapter;
+};
+
+static int sdk7786_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size,
+ union i2c_smbus_data *data)
+{
+ struct sdk7786_i2c_dev *dev = i2c_get_adapdata(adap);
+ int read = read_write I2C_SMBUS_READ;
+ u16 ctrl;
+
+ dev_dbg(adap-dev, addr %04x, command %02x, read_write %d, size %d\n,
+ addr, command, read_write, size);
+
+ ctrl = (addr 0x7f) 9 | (read 8);
+
+ switch (size) {
+ case I2C_SMBUS_BYTE:
+ if (read_write == I2C_SMBUS_WRITE)
+ ctrl |= command;
+ break;
+ case I2C_SMBUS_BYTE_DATA:
+ ctrl |= command;
+ break;
+ default:
+ dev_err(adap-dev, unsupported command %d\n, size);
+ return -EINVAL;
+ }
+
+ if (read) {
+ iowrite16(ctrl, dev-base + I2CCR);
+ data-byte = ioread16(dev-base + I2CDR) 0xff;
+ } else {
+ iowrite16(data-byte, dev-base + I2CDR);
+ iowrite16(ctrl, dev-base + I2CCR);
+ }
+
+ /* delay, as we have no way to check xfer status.. */
+ udelay(100);
+
+ return 0;
+}
+
+static u32 sdk7786_i2c_func(struct i2c_adapter *adapter)
+{
+ return I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA;
+}
+
+static const struct i2c_algorithm sdk7786_i2c_algo = {
+ .smbus_xfer = sdk7786_i2c_smbus_xfer,
+ .functionality = sdk7786_i2c_func,
+};
+
+static int __devinit sdk7786_i2c_probe(struct platform_device *pdev)
+{
+ struct sdk7786_i2c_dev *dev;
+ struct i2c_adapter *adap;
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(!res)) {
+ dev_err(pdev-dev, no mem resource\n);
+ return -ENODEV;
+ }
+
+ dev = kzalloc(sizeof(struct sdk7786_i2c_dev), GFP_KERNEL);
+ if (unlikely(!dev
Re: [patch 2/2] i2c: trivial endian casting fixes in i2c-highlander.c
On Mon, Dec 08, 2008 at 09:21:15AM +0100, Jean Delvare wrote: On Mon, 8 Dec 2008 12:07:58 +0900, Paul Mundt wrote: On Fri, Dec 05, 2008 at 02:46:05PM +0100, Jean Delvare wrote: Ben, Paul, any comment on this? It's fine with me, do you want to take this, or should I fold it in to my tree? Acked-by: Paul Mundt [EMAIL PROTECTED] This patch is in my tree and will go to Linus at the end of the week, unless you prefer to pick it. Through your tree is fine, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
