[PATCH] MFD: SEC: Fix reg_offset for interrupt registers
reg_offset is offset of the status/mask registers. Now, since status_base
and mask_base are pointing to corresponding first registers, reg_offset
should start from 0 otheriwse regmap_add_irq_chip will fail during probe.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
It is based on Samuel's for-next-merge branch of mfd-2.6 tree.
drivers/mfd/sec-irq.c | 102 -
1 file changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index c901fa5..0dd84e9 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -24,67 +24,67 @@
static struct regmap_irq s2mps11_irqs[] = {
[S2MPS11_IRQ_PWRONF] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRONF_MASK,
},
[S2MPS11_IRQ_PWRONR] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRONR_MASK,
},
[S2MPS11_IRQ_JIGONBF] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_JIGONBF_MASK,
},
[S2MPS11_IRQ_JIGONBR] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_JIGONBR_MASK,
},
[S2MPS11_IRQ_ACOKBF] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_ACOKBF_MASK,
},
[S2MPS11_IRQ_ACOKBR] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_ACOKBR_MASK,
},
[S2MPS11_IRQ_PWRON1S] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_PWRON1S_MASK,
},
[S2MPS11_IRQ_MRB] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S2MPS11_IRQ_MRB_MASK,
},
[S2MPS11_IRQ_RTC60S] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_RTC60S_MASK,
},
[S2MPS11_IRQ_RTCA1] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_RTCA1_MASK,
},
[S2MPS11_IRQ_RTCA2] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_RTCA2_MASK,
},
[S2MPS11_IRQ_SMPL] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_SMPL_MASK,
},
[S2MPS11_IRQ_RTC1S] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_RTC1S_MASK,
},
[S2MPS11_IRQ_WTSR] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S2MPS11_IRQ_WTSR_MASK,
},
[S2MPS11_IRQ_INT120C] = {
- .reg_offset = 3,
+ .reg_offset = 2,
.mask = S2MPS11_IRQ_INT120C_MASK,
},
[S2MPS11_IRQ_INT140C] = {
- .reg_offset = 3,
+ .reg_offset = 2,
.mask = S2MPS11_IRQ_INT140C_MASK,
},
};
@@ -92,146 +92,146 @@ static struct regmap_irq s2mps11_irqs[] = {
static struct regmap_irq s5m8767_irqs[] = {
[S5M8767_IRQ_PWRR] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_PWRR_MASK,
},
[S5M8767_IRQ_PWRF] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_PWRF_MASK,
},
[S5M8767_IRQ_PWR1S] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_PWR1S_MASK,
},
[S5M8767_IRQ_JIGR] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_JIGR_MASK,
},
[S5M8767_IRQ_JIGF] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_JIGF_MASK,
},
[S5M8767_IRQ_LOWBAT2] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_LOWBAT2_MASK,
},
[S5M8767_IRQ_LOWBAT1] = {
- .reg_offset = 1,
+ .reg_offset = 0,
.mask = S5M8767_IRQ_LOWBAT1_MASK,
},
[S5M8767_IRQ_MRB] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S5M8767_IRQ_MRB_MASK,
},
[S5M8767_IRQ_DVSOK2] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S5M8767_IRQ_DVSOK2_MASK,
},
[S5M8767_IRQ_DVSOK3] = {
- .reg_offset = 2,
+ .reg_offset = 1,
.mask = S5M8767_IRQ_DVSOK3_MASK,
},
[S5M8767_IRQ_DVSOK4] = {
- .reg_offset = 2,
+
Re: [PATCH] spi: s3c64xx: use clk_prepare_enable and clk_disable_unprepare
On Wed, Oct 03, 2012 at 08:30:12AM +0900, Thomas Abraham wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type
Arnd Bergmann wrote:
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction' [-
Wenum-compare]
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
BTW, don't we need following accordingly?
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 1a81c90..a0bb55e 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
if (tx) {
dma_data = sdd-tx_dma;
- dma_data-direction = DMA_TO_DEVICE;
+ dma_data-direction = DMA_MEM_TO_DEV;
chan_str = tx;
} else {
dma_data = sdd-rx_dma;
- dma_data-direction = DMA_FROM_DEVICE;
+ dma_data-direction = DMA_DEV_TO_MEM;
chan_str = rx;
}
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: spi-devel-gene...@lists.sourceforge.net
---
drivers/spi/spi-s3c64xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..2e44dd6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsignedch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: SAMSUNG: Add naming of s3c64xx-spi devices
José Miguel Gonçalves wrote: On 15-10-2012 15:58, Sylwester Nawrocki wrote: Hi Heiko, On 10/02/2012 02:43 PM, Heiko Stübner wrote: Commit a5238e360b71 (spi: s3c64xx: move controller information into driver data) introduced separate device names for the different subtypes of the spi controller but forgot to set these in the relevant machines. To fix this introduce a s3c64xx_spi_setname function and populate all Samsung arches with the correct names. The function resides in a new header, as the s3c64xx-spi.h contains driver platform data and should therefore at some later point move out of the Samsung include dir. Tested on a s3c2416-based machine. Signed-off-by: Heiko Stuebner he...@sntech.de Cc: sta...@vger.kernel.org This patch looks good to me. I've tested it on Exynos4412 SoC based board. And it fixes quite serious problem - broken SPI support on a all Samsung machs (non-dt) except s3c64xx in mainline v3.6 kernel. Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com (mach-exynos only) José Miguel, can you confirm it solves the problem for you ? The driver initialization problem is solved by this patch on my S3C2416 based board. Nevertheless, I didn’t have the time yet to test an actual SPI device connected to the bus. BTW, I think the two debug messages at the end of the s3c64xx_spi_probe() routine should be promoted from dev_dbg to dev_info in order to be shown on a normal kernel boot. You guys, thanks for fixing and testing. Looks good to me, applied. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi, Am Freitag, 14. September 2012, 11:08:51 schrieb Chander Kashyap: Perform clock disable/enable in runtime suspend/resume. Signed-off-by: Chander Kashyap chander.kash...@linaro.org It seems this patch breaks my S3C2416 based machine with 3.7-rc1. I'm not yet sure why, but the only response I get is loop of: mmc0: Timeout waiting for hardware interrupt. mmc0: Internal clock never stabilised. mmc0: Timeout waiting for hardware interrupt. mmc0: Internal clock never stabilised. This only happens on the hsmmc channel using the gpio-based card detect and even prevents the card from beeing fully detected. The other hsmmc channel using a permanent emmc seems to be working fine. And of course, when I revert this patch everything works fine again. I'll investigate further, but it'd be also ok if someone has a fix for this before me :-) . Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
Praveen Paneri wrote: platform_set_drvdata() required for driver's remove function, so adding it back. From v6: Added TODO for phy bindings with controller Dropped platform_set_drvdata() from driver probe This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 357 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung- usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..7b26e2d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,11 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. +TODO: Adding the PHY binding with controller(s) according to the under +developement generic PHY driver. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung- usbphy.c new file mode 100644 index 000..14c182f --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c Hi, Basically I agree and this is a good approach to support usb phy for Samsung stuff...but there are some comments ;) @@ -0,0 +1,357 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + IMHO, according to the file name, samsung-usbphy, SAMSUNG_ is better here? +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) Hmm...is this right? If so, need to use exact name for the definition. See arch/arm/mach-exynos/include/mach/regs-usb-phy.h +#define EXYNOS4_PHYPWR_SLEEP (1 5) Ditto. + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) MODE_USB11? +#define S3C_PHYCLK_EXT_OSC (1 5) +#define
RE: [PATCH v3 1/6] dts: exynos: add device tree support for exynos5 hdmi
Rahul Sharma wrote:
This patch adds support for device tree based discovery for exynos5
hdmi. Hdmi node is also renamed with exynos5-hdmi.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/drm/exynos/hdmi.txt| 22
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6 +
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
5 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmi.txt
[...]
+ hdmi {
+ compatible = samsung,exynos5-hdmi;
+ reg = 0x1453 0x10;
+ interrupts = 0 95 0;
+ hpd-gpio = gpx3 7 0xf 1 3;
+ };
\ No newline at end of file
What's this?
[...]
+ hdmi@1453 {
+ hdmi {
+ hpd-gpio = gpx3 7 0xf 1 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index f69e389..ec7ea2d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -492,4 +492,10 @@
#gpio-cells = 4;
};
};
+
+ hdmi@1453 {
Ditto.
[...]
+#define EXYNOS5_PA_HDMI 0x1453
I think, we don't need this because see below.
[...]
+ OF_DEV_AUXDATA(samsung,exynos5-hdmi, EXYNOS5_PA_HDMI,
+ exynos5-hdmi, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5-hdmi, 0x1453, exynos5-hdmi,
NULL),
I think, if the address as defined above is used only here, let's just the
value because nobody don't know it is the address.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/6] dts: exynos: add device tree support for exynos5 mixer
Rahul Sharma wrote: This patch adds support for device tree based discovery for exynos5 mixer. Mixer node is also renamed with exynos5-mixer. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- .../devicetree/bindings/drm/exynos/mixer.txt | 15 +++ arch/arm/boot/dts/exynos5250.dtsi |6 ++ arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++ 4 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/mixer.txt Basically, same comments on your 1/6 patch. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/6] arm: exynos: add dt based support for exynos5 hdmi
Rahul Sharma wrote: Mr. Park, Looks good to me. Shall I divide the patch-set into two groups and re-post them? No, you don't need to divide this series. It should be OK to be sent to upstream via Samsung tree. But see my small comments on your patch before that. BTW, I'm not sure about 6th patch which removes to support non-DT for exynos4210 in Samsung tree because as you commented on the patch, the removed code should be replaced by corresponding patch is in exynos drm driver. So I think, topic branch I will provide for exynos drm tree can be a way to solve it. Or Kyungmin's suggestion can be a way for it too. Let you know which one is better...when I pick this up in my tree. regards, Rahul Sharma. On Wed, Oct 17, 2012 at 9:09 AM, Kyungmin Park kyungmin.p...@samsung.com wrote: Hi, It's common case, one topic but two different tree. So I suggest merge it at samsung sub-soc tree and drm parts will be merged after arm-soc tree is merged. since arm-soc tree collect arm soc-soc and merged early at merge window. then drm tree will be merged later. Until that time, drm patches are hold only at local git. How do you think? Kyungmin, thanks for your suggestion :) Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
This patch set adds following features - Seggregate PCI specific code in ufshcd.c and corrected copyright - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfer size drivers/scsi/ufs/Kconfig | 87 +--- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufs.h | 42 ++--- drivers/scsi/ufs/ufshcd-pci.c| 211 ++ drivers/scsi/ufs/ufshcd-pltfrm.c | 205 ++ drivers/scsi/ufs/ufshcd.c| 433 +++-- drivers/scsi/ufs/ufshcd.h| 200 ++ drivers/scsi/ufs/ufshci.h| 42 ++--- 8 files changed, 786 insertions(+), 436 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c create mode 100644 drivers/scsi/ufs/ufshcd.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
This patch seggregates the PCI specific code in ufshcd.c to make it ready for splitting into core ufs driver and PCI glue driver. Also copyright header modification to remove extra warranty disclaim. Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Namjae Jeon linkinj...@gmail.com Signed-off-by: Vinayak Holikatti vinholika...@gmail.com Signed-off-by: Santosh Yaraganavi santos...@gmail.com --- drivers/scsi/ufs/Kconfig | 50 +++ drivers/scsi/ufs/ufs.h| 42 ++ drivers/scsi/ufs/ufshcd.c | 358 ++--- drivers/scsi/ufs/ufshci.h | 42 ++ 4 files changed, 256 insertions(+), 236 deletions(-) diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index 8f27f9d..9c84569 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -2,45 +2,35 @@ # Kernel configuration file for the UFS Host Controller # # This code is based on drivers/scsi/ufs/Kconfig -# Copyright (C) 2011 Samsung Samsung India Software Operations +# Copyright (C) 2011-2012 Samsung India Software Operations +# +# Authors: +# Santosh Yaraganavi santosh...@samsung.com +# Vinayak Holikatti h.vina...@samsung.com # -# Santosh Yaraganavi santosh...@samsung.com -# Vinayak Holikatti h.vina...@samsung.com - # 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; either version 2 # of the License, or (at your option) any later version. - +# See the COPYING file in the top-level directory or visit +# http://www.gnu.org/licenses/gpl-2.0.html +# # 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. - -# NO WARRANTY -# THE PROGRAM IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR -# CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT -# LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, -# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is -# solely responsible for determining the appropriateness of using and -# distributing the Program and assumes all risks associated with its -# exercise of rights under this Agreement, including but not limited to -# the risks and costs of program errors, damage to or loss of data, -# programs or equipment, and unavailability or interruption of operations. - -# DISCLAIMER OF LIABILITY -# NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY -# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -# DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND -# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR -# TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE -# USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED -# HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES - -# 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 Street, Fifth Floor, Boston, MA 02110-1301, -# USA. +# +# This program is provided AS IS and WITH ALL FAULTS and +# without warranty of any kind. You are solely responsible for +# determining the appropriateness of using and distributing +# the program and assume all risks associated with your exercise +# of rights with respect to the program, including but not limited +# to infringement of third party rights, the risks and costs of +# program errors, damage to or loss of data, programs or equipment, +# and unavailability or interruption of operations. Under no +# circumstances will the contributor of this Program be liable for +# any damages of any kind arising from your use or distribution of +# this program. config SCSI_UFSHCD tristate Universal Flash Storage host controller driver diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index b207529..4b3d611 100644 --- a/drivers/scsi/ufs/ufs.h +++ b/drivers/scsi/ufs/ufs.h @@ -4,43 +4,33 @@ * This code is based on drivers/scsi/ufs/ufs.h * Copyright (C) 2011-2012 Samsung India Software Operations * - * Santosh Yaraganavi santosh...@samsung.com - * Vinayak Holikatti h.vina...@samsung.com + * Authors: + * Santosh Yaraganavi santosh...@samsung.com + * Vinayak Holikatti h.vina...@samsung.com * * 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; either version 2 * of the License, or (at your option) any later version. + * See the COPYING file in the top-level directory or visit + * http://www.gnu.org/licenses/gpl-2.0.html * * This program is distributed in the hope that it will be useful, * but WITHOUT
[PATCH V4 2/4] [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver
This patch separates PCI code from ufshcd.c and makes it as a
core driver module and adds a new file ufshcd-pci.c as PCI glue
driver.
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Namjae Jeon linkinj...@gmail.com
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 26 +++-
drivers/scsi/ufs/Makefile |1 +
drivers/scsi/ufs/ufshcd-pci.c | 211 +++
drivers/scsi/ufs/ufshcd.c | 323 +
drivers/scsi/ufs/ufshcd.h | 200 +
5 files changed, 437 insertions(+), 324 deletions(-)
create mode 100644 drivers/scsi/ufs/ufshcd-pci.c
create mode 100644 drivers/scsi/ufs/ufshcd.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 9c84569..d77ae97 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -33,7 +33,27 @@
# this program.
config SCSI_UFSHCD
- tristate Universal Flash Storage host controller driver
- depends on PCI SCSI
+ tristate Universal Flash Storage Controller Driver Core
+ depends on SCSI
---help---
- This is a generic driver which supports PCIe UFS Host controllers.
+ This selects the support for UFS devices in Linux, say Y and make
+ sure that you know the name of your UFS host adapter (the card
+ inside your computer that speaks the UFS protocol, also
+ called UFS Host Controller), because you will be asked for it.
+ The module will be called ufshcd.
+
+ To compile this driver as a module, choose M here and read
+ file:Documentation/scsi/ufs.txt.
+ However, do not compile this as a module if your root file system
+ (the one containing the directory /) is located on a UFS device.
+
+config SCSI_UFSHCD_PCI
+ tristate PCI bus based UFS Controller support
+ depends on SCSI_UFSHCD PCI
+ ---help---
+ This selects the PCI UFS Host Controller Interface.
+ Most controllers found today are PCI devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index adf7895..9eda0df 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,2 +1,3 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
+obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
new file mode 100644
index 000..ba86b5e
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -0,0 +1,211 @@
+/*
+ * Universal Flash Storage Host controller driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pci.c
+ * Copyright (C) 2011-2012 Samsung India Software Operations
+ *
+ * Authors:
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * 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; either version 2
+ * of the License, or (at your option) any later version.
+ * See the COPYING file in the top-level directory or visit
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ *
+ * 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.
+ *
+ * This program is provided AS IS and WITH ALL FAULTS and
+ * without warranty of any kind. You are solely responsible for
+ * determining the appropriateness of using and distributing
+ * the program and assume all risks associated with your exercise
+ * of rights with respect to the program, including but not limited
+ * to infringement of third party rights, the risks and costs of
+ * program errors, damage to or loss of data, programs or equipment,
+ * and unavailability or interruption of operations. Under no
+ * circumstances will the contributor of this Program be liable for
+ * any damages of any kind arising from your use or distribution of
+ * this program.
+ */
+
+#include ufshcd.h
+#include linux/pci.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_pci_suspend - suspend power management function
+ * @pdev: pointer to PCI device handle
+ * @state: power state
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ /*
+* TODO:
+* 1. Call ufshcd_suspend
+* 2. Do bus specific power management
+*/
+
+ return -ENOSYS;
+}
+
+/**
+ * ufshcd_pci_resume - resume power management function
+ * @pdev: pointer to PCI device handle
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pci_resume(struct pci_dev *pdev)
+{
+ /*
+* TODO:
+* 1. Call ufshcd_resume.
+* 2.
[PATCH V4 4/4] [SCSI] ufs: Correct the expected data transfer size
This patch corrects the expected data transfer size of the command UPIU. The current implementation of cmd-transfersize is wrong as it probably equal to sector size. With this implementation the transfer size is updated correctly Reported-by: KOBAYASHI Yoshitake yoshitake.kobaya...@toshiba.co.jp Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Namjae Jeon linkinj...@gmail.com Signed-off-by: Santosh Yaraganavi santos...@gmail.com Signed-off-by: Vinayak Holikatti vinholika...@gmail.com --- drivers/scsi/ufs/ufshcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 5d7bd47..57c16ec 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -478,7 +478,7 @@ static void ufshcd_compose_upiu(struct ufshcd_lrb *lrbp) ucd_cmd_ptr-header.dword_2 = 0; ucd_cmd_ptr-exp_data_transfer_len = - cpu_to_be32(lrbp-cmd-transfersize); + cpu_to_be32(lrbp-cmd-sdb.length); memcpy(ucd_cmd_ptr-cdb, lrbp-cmd-cmnd, -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
This patch adds Platform glue driver for ufshcd.
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Namjae Jeon linkinj...@gmail.com
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pltfrm.c | 205 ++
3 files changed, 217 insertions(+), 0 deletions(-)
create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index d77ae97..96e1721 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -57,3 +57,14 @@ config SCSI_UFSHCD_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFSHCD_PLATFORM
+ tristate Platform based UFS Controller support
+ depends on SCSI_UFSHCD
+ ---help---
+ This selects the UFS host controller support. If you have a
+ platform with UFS controller, say Y or M here.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9eda0df..1e5bd48 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,3 +1,4 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
+obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
new file mode 100644
index 000..73ac7c7
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -0,0 +1,205 @@
+/*
+ * Universal Flash Storage Host controller driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd.c
+ * Copyright (C) 2011-2012 Samsung India Software Operations
+ *
+ * Authors:
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * 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; either version 2
+ * of the License, or (at your option) any later version.
+ * See the COPYING file in the top-level directory or visit
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ *
+ * 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.
+ *
+ * This program is provided AS IS and WITH ALL FAULTS and
+ * without warranty of any kind. You are solely responsible for
+ * determining the appropriateness of using and distributing
+ * the program and assume all risks associated with your exercise
+ * of rights with respect to the program, including but not limited
+ * to infringement of third party rights, the risks and costs of
+ * program errors, damage to or loss of data, programs or equipment,
+ * and unavailability or interruption of operations. Under no
+ * circumstances will the contributor of this Program be liable for
+ * any damages of any kind arising from your use or distribution of
+ * this program.
+ */
+
+#include ufshcd.h
+#include linux/platform_device.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_pltfrm_suspend - suspend power management function
+ * @pdev: pointer to Platform device handle
+ * @mesg: power state
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_suspend(struct platform_device *pdev,
+pm_message_t mesg)
+{
+ /*
+* TODO:
+* 1. Call ufshcd_suspend
+* 2. Do bus specific power management
+*/
+
+ return -ENOSYS;
+}
+
+/**
+ * ufshcd_pltfrm_resume - resume power management function
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_resume(struct platform_device *pdev)
+{
+ /*
+* TODO:
+* 1. Call ufshcd_resume.
+* 2. Do bus specific wake up
+*/
+
+ return -ENOSYS;
+}
+#endif
+
+/**
+ * ufshcd_pltfrm_probe - probe routine of the driver
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int __devinit
+ufshcd_pltfrm_probe(struct platform_device *pdev)
+{
+ struct ufs_hba *hba;
+ void __iomem *mmio_base;
+ struct resource *mem_res;
+ struct resource *irq_res;
+ resource_size_t mem_size;
+ int err;
+ struct device *dev = pdev-dev;
+
+ mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem_res) {
+ dev_err(pdev-dev,
+ %s: Memory resource not available\n, __FILE__);
+ err = -ENODEV;
+ goto out_error;
+ }
+
+ mem_size = resource_size(mem_res);
+ if
Re: [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi, On Wed, Oct 17, 2012 at 4:30 PM, Kukjin Kim kgene@samsung.com wrote: Praveen Paneri wrote: platform_set_drvdata() required for driver's remove function, so adding it back. From v6: Added TODO for phy bindings with controller Dropped platform_set_drvdata() from driver probe This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 357 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung- usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..7b26e2d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,11 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. +TODO: Adding the PHY binding with controller(s) according to the under +developement generic PHY driver. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung- usbphy.c new file mode 100644 index 000..14c182f --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c Hi, Basically I agree and this is a good approach to support usb phy for Samsung stuff...but there are some comments ;) @@ -0,0 +1,357 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + IMHO, according to the file name, samsung-usbphy, SAMSUNG_ is better here? Sure I will change this for register names and drop S3C_ from bit definitions. +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) Hmm...is this right? If so, need to use exact name for the definition. Name should be changed, will do that. See arch/arm/mach-exynos/include/mach/regs-usb-phy.h +#define EXYNOS4_PHYPWR_SLEEP (1 5) Ditto. +
Re: [PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type
On Wednesday 17 October 2012, Kukjin Kim wrote:
BTW, don't we need following accordingly?
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 1a81c90..a0bb55e 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
if (tx) {
dma_data = sdd-tx_dma;
- dma_data-direction = DMA_TO_DEVICE;
+ dma_data-direction = DMA_MEM_TO_DEV;
chan_str = tx;
} else {
dma_data = sdd-rx_dma;
- dma_data-direction = DMA_FROM_DEVICE;
+ dma_data-direction = DMA_DEV_TO_MEM;
chan_str = rx;
}
Yes, you are absolutely right, sorry for not seeing that earlier.
New version below.
Arnd
From c10356b9846b13651a8a24c3a31e029ffe6eafd9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Mon, 30 Apr 2012 16:31:27 +
Subject: [PATCH] spi/s3c64xx: use correct dma_transfer_direction type
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction'
[-Wenum-compare]
As pointed out by Kukjin Kim, this also changes the use of constants
from DMA_FROM_DEVICE/DMA_TO_DEVICE to DMA_DEV_TO_MEM/DMA_MEM_TO_DEV.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Kukjin Kim kgene@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: spi-devel-gene...@lists.sourceforge.net
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..cd43b4b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsignedch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
@@ -1065,11 +1065,11 @@ static int __devinit s3c64xx_spi_get_dmares(
if (tx) {
dma_data = sdd-tx_dma;
- dma_data-direction = DMA_TO_DEVICE;
+ dma_data-direction = DMA_MEM_TO_DEV;
chan_str = tx;
} else {
dma_data = sdd-rx_dma;
- dma_data-direction = DMA_FROM_DEVICE;
+ dma_data-direction = DMA_DEV_TO_MEM;
chan_str = rx;
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
Hi Sachin,
On 10/17/2012 01:11 PM, Sachin Kamat wrote:
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
I think this statement is misleading. In my understanding it is not the
common clock framework requirement to use clk_{enable/disable}_prepare
in place of clk_enable/disable. The requirement is to call clk_prepare
before first clk_enable call and to call clk_unprepare after clk_disable
and before clk_put.
You need to be careful with those replacements, since the clk *_(un)prepare
functions may sleep, i.e. they must not be called from atomic context.
Most of the s5p-* drivers have already added support for clk_(un)prepare.
Thus most of your changes in this patch are not needed. I seem to have only
missed fimc-mdevice.c, other modules are already reworked
$ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
drivers/media/platform/s5p-fimc/fimc-core.c-
drivers/media/platform/s5p-fimc/fimc-core.c-for (i = 0; i
MAX_FIMC_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/fimc-core.c-fimc-clock[i] =
clk_get(fimc-pdev-dev, fimc_clocks[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-if
(IS_ERR(fimc-clock[i]))
drivers/media/platform/s5p-fimc/fimc-core.c-goto err;
drivers/media/platform/s5p-fimc/fimc-core.c:ret =
clk_prepare(fimc-clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-if (ret 0) {
drivers/media/platform/s5p-fimc/fimc-core.c-
clk_put(fimc-clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-fimc-clock[i]
= NULL;
drivers/media/platform/s5p-fimc/fimc-core.c-goto err;
drivers/media/platform/s5p-fimc/fimc-core.c-}
--
drivers/media/platform/s5p-fimc/fimc-lite.c-
drivers/media/platform/s5p-fimc/fimc-lite.c-fimc-clock =
clk_get(fimc-pdev-dev, FLITE_CLK_NAME);
drivers/media/platform/s5p-fimc/fimc-lite.c-if (IS_ERR(fimc-clock))
drivers/media/platform/s5p-fimc/fimc-lite.c-return
PTR_ERR(fimc-clock);
drivers/media/platform/s5p-fimc/fimc-lite.c-
drivers/media/platform/s5p-fimc/fimc-lite.c:ret = clk_prepare(fimc-clock);
drivers/media/platform/s5p-fimc/fimc-lite.c-if (ret 0) {
drivers/media/platform/s5p-fimc/fimc-lite.c-clk_put(fimc-clock);
drivers/media/platform/s5p-fimc/fimc-lite.c-fimc-clock = NULL;
drivers/media/platform/s5p-fimc/fimc-lite.c-}
drivers/media/platform/s5p-fimc/fimc-lite.c-return ret;
--
drivers/media/platform/s5p-fimc/mipi-csis.c-
drivers/media/platform/s5p-fimc/mipi-csis.c-for (i = 0; i
NUM_CSIS_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/mipi-csis.c-state-clock[i] =
clk_get(dev, csi_clock_name[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c-if
(IS_ERR(state-clock[i]))
drivers/media/platform/s5p-fimc/mipi-csis.c-goto err;
drivers/media/platform/s5p-fimc/mipi-csis.c:ret =
clk_prepare(state-clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c-if (ret 0) {
drivers/media/platform/s5p-fimc/mipi-csis.c-
clk_put(state-clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c-state-clock[i]
= NULL;
drivers/media/platform/s5p-fimc/mipi-csis.c-goto err;
drivers/media/platform/s5p-fimc/mipi-csis.c-}
I would prefer you have added the required changes at fimc_md_get_clocks()
and fimc_md_put_clocks() functions.
Please make sure you don't add those clk_(un)prepare calls where it is
net needed.
$ git grep clk_prepare\|clk_unprepare -- drivers/media/platform/s5p-*
drivers/media/platform/s5p-fimc/fimc-core.c:
clk_unprepare(fimc-clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c:ret =
clk_prepare(fimc-clock[i]);
drivers/media/platform/s5p-fimc/fimc-lite.c:clk_unprepare(fimc-clock);
drivers/media/platform/s5p-fimc/fimc-lite.c:ret = clk_prepare(fimc-clock);
drivers/media/platform/s5p-fimc/mipi-csis.c:
clk_unprepare(state-clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c:ret =
clk_prepare(state-clock[i]);
drivers/media/platform/s5p-g2d/g2d.c: ret = clk_prepare(dev-clk);
drivers/media/platform/s5p-g2d/g2d.c: ret = clk_prepare(dev-gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev-gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev-clk);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev-gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev-clk);
drivers/media/platform/s5p-jpeg/jpeg-core.c:clk_prepare_enable(jpeg-clk);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:ret =
clk_prepare(pm-clock_gate);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:ret = clk_prepare(pm-clock);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:clk_unprepare(pm-clock_gate);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:clk_unprepare(pm-clock_gate);
Re: [PATCH 1/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
Hi Sylwester,
Thanks for the review.
On 17 October 2012 20:03, Sylwester Nawrocki s.nawro...@samsung.com wrote:
Hi Sachin,
On 10/17/2012 01:11 PM, Sachin Kamat wrote:
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
You need to be careful with those replacements, since the clk *_(un)prepare
functions may sleep, i.e. they must not be called from atomic context.
OK.
Most of the s5p-* drivers have already added support for clk_(un)prepare.
Thus most of your changes in this patch are not needed. I seem to have only
missed fimc-mdevice.c, other modules are already reworked
I did not find these changes in your tree. Please let me know the
branch where these changes are available.
$ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
drivers/media/platform/s5p-fimc/fimc-core.c-
drivers/media/platform/s5p-fimc/fimc-core.c-for (i = 0; i
MAX_FIMC_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/fimc-core.c-fimc-clock[i] =
clk_get(fimc-pdev-dev, fimc_clocks[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-if
(IS_ERR(fimc-clock[i]))
I would prefer you have added the required changes at fimc_md_get_clocks()
and fimc_md_put_clocks() functions.
Ok. I will check this.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
On 10/17/2012 05:35 PM, Sachin Kamat wrote:
Most of the s5p-* drivers have already added support for clk_(un)prepare.
Thus most of your changes in this patch are not needed. I seem to have only
missed fimc-mdevice.c, other modules are already reworked
I did not find these changes in your tree. Please let me know the
branch where these changes are available.
Are in Linus' tree, for quite long already, commits:
11a37c709797cc56f48905e68a3099b79cf08850
[media] s5p-g2d: Added support for clk_prepare
bd7de99d67f778f4ee272346322c0b9cb378
[media] s5p-fimc: convert to clk_prepare()/clk_unprepare()
eb732518e0db585376f95256b18b2149240e3ad3
[media] s5p-mfc: Added support for clk_prepare
Please note there was the media drivers reorganization recently, e.g.
drivers/media/video/s5p-* changed to drivers/media/platform/s5p-*.
$ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
drivers/media/platform/s5p-fimc/fimc-core.c-
drivers/media/platform/s5p-fimc/fimc-core.c-for (i = 0; i
MAX_FIMC_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/fimc-core.c-fimc-clock[i] =
clk_get(fimc-pdev-dev, fimc_clocks[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-if
(IS_ERR(fimc-clock[i]))
I would prefer you have added the required changes at fimc_md_get_clocks()
and fimc_md_put_clocks() functions.
Ok. I will check this.
Thanks.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
On Wed, Oct 17, 2012 at 08:00:00PM +0900, Kukjin Kim wrote:
+static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
+{
+ struct clk *ref_clk;
+ int refclk_freq = 0;
+
+ ref_clk = clk_get(sphy-dev, xusbxti);
+ if (IS_ERR(ref_clk)) {
IS_ERR_OR_NULL(ref_clk)?
For the N'th time, NO. IS_ERR is correct here.
+ dev_err(sphy-dev, Failed to get reference clock\n);
+ return PTR_ERR(ref_clk);
Look, it's the ABI. Not only that but it's also TOTALLY AND UTTERLY WRONG
to use IS_ERR_OR_NULL(foo) and then follow it with return PTR_ERR(foo).
You end up returning ZERO.
Stop telling people to use IS_ERR_OR_NULL without properly thinking about
it first. Virtually every single one of these done this way is a BUG.
Are we clear on this?
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
IS_ERR_OR_NULL - please STOP telling people to use this on a whim
People,
This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.
I'm geting sick and tired of telling people about this. I've just
floated the idea of removing IS_ERR_OR_NULL from the kernel tree because
it's one of the most incorrectly used and abused macros we have in the
source tree.
It would be one thing if this was only being done by people who are
submitting new code, but it's far worse than that. Reviewers who should
know better are telling people to use it _incorrectly_.
Reviewers really need to think about your review comments. Looking
through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(),
many of them are *buggy*.
Take a moment to think about this:
int error_value(struct device *dev, void *foo)
{
if (IS_ERR_OR_NULL(foo))
return PTR_ERR(foo);
return 0;
}
Consider the value this function returns for three arguments:
1. an errno encoded pointer
2. a NULL pointer.
3. a valid pointer.
If you can't see the problem, then *do* *not* tell anyone to use
IS_ERR_OR_NULL(), because you do *not* have the understanding necessary
to make that judgement yourself - you're probably telling people to
create buggy code.
Here's the list so far of what looks like buggy uses specific to ARM.
There _are_ others elsewhere in the kernel.
drivers/media/video/s5p-mfc/s5p_mfc.c: if (IS_ERR_OR_NULL(dev-alloc_ctx[0])) {
drivers/media/video/s5p-mfc/s5p_mfc.c- ret =
PTR_ERR(dev-alloc_ctx[0]);
drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_res;
drivers/media/video/s5p-mfc/s5p_mfc.c- }
--
drivers/media/video/s5p-mfc/s5p_mfc.c: if (IS_ERR_OR_NULL(dev-alloc_ctx[1])) {
drivers/media/video/s5p-mfc/s5p_mfc.c- ret =
PTR_ERR(dev-alloc_ctx[1]);
drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_mem_init_ctx_1;
drivers/media/video/s5p-mfc/s5p_mfc.c- }
--
drivers/staging/omapdrm/omap_dmm_tiler.c: if (IS_ERR_OR_NULL(txn))
drivers/staging/omapdrm/omap_dmm_tiler.c- return PTR_ERR(txn);
drivers/staging/omapdrm/omap_dmm_tiler.c-
drivers/staging/omapdrm/omap_dmm_tiler.c- tcm_for_each_slice(slice,
*area, area_s) {
--
drivers/staging/omap-thermal/omap-bandgap.c:if (IS_ERR_OR_NULL(bg_ptr)) {
drivers/staging/omap-thermal/omap-bandgap.c-dev_err(pdev-dev,
failed to fetch platform data\n);
drivers/staging/omap-thermal/omap-bandgap.c-return PTR_ERR(bg_ptr);
drivers/staging/omap-thermal/omap-bandgap.c-}
--
drivers/staging/omap-thermal/omap-thermal-common.c: if
(IS_ERR_OR_NULL(data-omap_thermal)) {
drivers/staging/omap-thermal/omap-thermal-common.c-
dev_err(bg_ptr-dev, thermal zone device is NULL\n);
drivers/staging/omap-thermal/omap-thermal-common.c- return
PTR_ERR(data-omap_thermal);
drivers/staging/omap-thermal/omap-thermal-common.c- }
--
drivers/staging/omap-thermal/omap-thermal-common.c: if
(IS_ERR_OR_NULL(freq_table)) {
drivers/staging/omap-thermal/omap-thermal-common.c-
dev_err(bg_ptr-dev,
drivers/staging/omap-thermal/omap-thermal-common.c- %s:
failed to get cpufreq table (%p)\n,
drivers/staging/omap-thermal/omap-thermal-common.c-
__func__, freq_table);
--
drivers/staging/omap-thermal/omap-thermal-common.c: if
(IS_ERR_OR_NULL(data-cool_dev)) {
drivers/staging/omap-thermal/omap-thermal-common.c-
dev_err(bg_ptr-dev,
drivers/staging/omap-thermal/omap-thermal-common.c- Failed
to register cpufreq cooling device\n);
drivers/staging/omap-thermal/omap-thermal-common.c- return
PTR_ERR(data-cool_dev);
--
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c: if (IS_ERR_OR_NULL(sgt)) {
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- ret = PTR_ERR(sgt);
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- goto err_buf_detach;
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- }
--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c: if (IS_ERR_OR_NULL(helper-fb))
{
drivers/gpu/drm/exynos/exynos_drm_fbdev.c- DRM_ERROR(failed to
create drm framebuffer.\n);
drivers/gpu/drm/exynos/exynos_drm_fbdev.c- ret =
PTR_ERR(helper-fb);
drivers/gpu/drm/exynos/exynos_drm_fbdev.c- goto out;
--
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IS_ERR_OR_NULL - please STOP telling people to use this on a whim
On 17/10/12 20:41 +0100, Russell King - ARM Linux wrote:
People,
This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.
I'm geting sick and tired of telling people about this. I've just
floated the idea of removing IS_ERR_OR_NULL from the kernel tree because
it's one of the most incorrectly used and abused macros we have in the
source tree.
This makes me sad. I was responsible for its introduction, and my motive
was exactly yours in sending the above.
It would be one thing if this was only being done by people who are
submitting new code, but it's far worse than that. Reviewers who should
know better are telling people to use it _incorrectly_.
Reviewers really need to think about your review comments. Looking
through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(),
many of them are *buggy*.
Take a moment to think about this:
int error_value(struct device *dev, void *foo)
{
if (IS_ERR_OR_NULL(foo))
return PTR_ERR(foo);
return 0;
}
Consider the value this function returns for three arguments:
1. an errno encoded pointer
2. a NULL pointer.
3. a valid pointer.
If you can't see the problem, then *do* *not* tell anyone to use
IS_ERR_OR_NULL(), because you do *not* have the understanding necessary
to make that judgement yourself - you're probably telling people to
create buggy code.
The problem I saw was functions returning -ERRORs or NULL. There were
too many, and there was too much sloppy code inconsistently handling one
or either of the two, and not always both. I did consider trying to fix
some of the core functions that were returning -ERRORs or NULL to the
drivers I was involved in, but it seemed like there were too many, and
that would be too brave. I imagined that my macro would help catch
that undesirable situation, and permit people to map the error onto
whatever was most appropriate to propagate on.
The idea of them propagating the undesirable problem up further in the call
chain is the exact antithesis of what I intended.
Thank you for highlighting the issue I didn't foresee (neither did my
colleagues at Nokia, they made good use of it fairly quickly) and in
such unambiguous terms. Better to nip it in the bud, certainly.
Here's the list so far of what looks like buggy uses specific to ARM.
There _are_ others elsewhere in the kernel.
drivers/media/video/s5p-mfc/s5p_mfc.c: if
(IS_ERR_OR_NULL(dev-alloc_ctx[0])) {
drivers/media/video/s5p-mfc/s5p_mfc.c- ret =
PTR_ERR(dev-alloc_ctx[0]);
drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_res;
drivers/media/video/s5p-mfc/s5p_mfc.c- }
...
:-(
So, what to do? It can and has been used sensibly, so I don't think removing
it is the best option.
Phil
pcarm...@nokia.com is no more, I'm now pc+l...@asdf.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IS_ERR_OR_NULL - please STOP telling people to use this on a whim
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote: So, what to do? It can and has been used sensibly, so I don't think removing it is the best option. Well, the first thing that needs to be done is a full review of every user and fixes applied. The second thing is that we need eyes on code _and_ review comments, and educate those who are telling people to use IS_ERR_OR_NULL() whenever they see an IS_ERR() to think about the code a little more - that's kind of the purpose of my email. Unfortunately, it's going to take time to achieve a change, and if I end up being the only one who's spotting these errors, I'm going to get incredibly pissed off at doing so (because it will feel like I'm being ignored when there's a constant stream of it.) Another thing would be to work out whether we can get checkpatch to detect usage of IS_ERR_OR_NULL(p) followed by PTR_ERR(p) without any explicit NULL checks against p in the same block. That's probably going to be interesting to code up in perl. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi Heiko, Sorry, i didn't check this patch with s3c2416. (i didn't have the s3c2416 board.) If you have a problem, i think good that revert this patch for fixing your problem. Also, i will check and share the result. Best Regards, Jaehoon Chung On 10/17/2012 06:15 PM, Heiko Stübner wrote: Hi, Am Freitag, 14. September 2012, 11:08:51 schrieb Chander Kashyap: Perform clock disable/enable in runtime suspend/resume. Signed-off-by: Chander Kashyap chander.kash...@linaro.org It seems this patch breaks my S3C2416 based machine with 3.7-rc1. I'm not yet sure why, but the only response I get is loop of: mmc0: Timeout waiting for hardware interrupt. mmc0: Internal clock never stabilised. mmc0: Timeout waiting for hardware interrupt. mmc0: Internal clock never stabilised. This only happens on the hsmmc channel using the gpio-based card detect and even prevents the card from beeing fully detected. The other hsmmc channel using a permanent emmc seems to be working fine. And of course, when I revert this patch everything works fine again. I'll investigate further, but it'd be also ok if someone has a fix for this before me :-) . Heiko -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
