Re: [PATCH 2/2] iommu/exynos: Follow kernel coding style for __sysmmu_enable return type
Yes, of course, I have no objections. On Fri, Aug 16, 2013 at 1:21 PM, Cho KyongHo pullip@samsung.com wrote: On Wed, 14 Aug 2013 15:15:49 +0200, 'Joerg Roedel' wrote: KyongHo, On Fri, Jul 26, 2013 at 07:46:01PM +0900, Cho KyongHo wrote: __sysmmu_enable() must return 1 if it is called with the same page table. I have fixed it exynos_iommu_attach_device() to always return zero on success in the next patchset which I will post today. Thank you. When you are fine with these patches please put them on-top of your patch-set when you re-submit. I will take them from there then. Ok. Antonios, Would you mind if I submit your 2 patches on top of my patches with your signed-off? KyongHo. Joerg -- 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 V5] ARM: dts: Change i2s compatible string on exynos5250
On 08/16/13 16:53, Tomasz Figa wrote: Hi Kukjin, [...] - compatible = samsung,i2s-v5; + compatible = samsung,s5pv210-i2s; Device tree reviewers, this is something to look out for in the future. Some samsung platforms/drivers use samsung,chip-ip, others samsung,ip-chip. I don't personally care much one way or another, but it really should be consistent. Hmm...I think, if samsung,ip name-ip version is possible, it would be nice. I remember there are no versions in datasheet for some IPs but something have like i2s and mfc. So samsung,ip-version is used for only i2s and mfc. But actually there are versions for Samsung IPs, no comments for that in datasheet. So I think, if Samsung can provide the specific version of Samsung IPs, we can use that like other platforms. I will prepare some table for that after meeting with Samsung hardware IP team so that samsung platform use one format samsung,ip-version. Sorry, I don't think this is a good idea, unless you can force the IP team to release a version table containing version of _every_ IP for _every_ released SoC, including those historical ones, like S3C24xx and S3C64xx. Of course such tables should be available publicly. It's different issue and I agree with Mark Brown's comments. In addition, there might be other funny things going on with IPs and their surroundings, that could make a need to create several separate compatible values for the same IP revision, but on different SoCs, because it was integrated in a slightly different way. I believe we have choses the samsung,chip-ip scheme to avoid being dependent upon data that is not always publicly available, which is more future- (and past-) proof and also solves the integration problem. Well, I don't think so, because Samsung is no more just SoC vendor. Actually Samsung is providing just IP to customers, I think, they don't like to use the name, exynos for their SoC or Chip, because exynos, s3c or s5p whatever is Samsung's SoC brand name. If so, I think, my suggestion is more reasonable. See the example of Synopsys and ARM primecell...that's why I will try to do it. But I know I need to get agreement from DT guys and maybe I need more time than I expect ;-) Thanks, Kukjin -- 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 0/4] ARM: S3C24XX: add dmaengine based dma-driver
On 08/14/13 20:59, Heiko Stübner wrote: This series tries to provide a basic dmaengine driver for the s3c24xx SoCs to subsequently retire the old one with custom API. Since v1 three big changes happened (appart from fixing received comments): For one the limitation of sg-lists to 1 element is gone.Secondly the specifics of the virtual channels (target bus, handshake, etc) are not encoded with channel ids but in the platformdata - making a later dt binding easier, as these informations can there be gathered by the xlate function. And lastly I also added a preliminary mechanism to handle the specific needs for the earlier variants of the driver. While s3c2443 and later can use any channel for any peripheral with just marking the target-peripheral-id in a register, earlier SoCs can only use specific channels and the target-ids also vary depending on the channel. Therefore on newer SoCs the chansel element only needs to contain the requested target-id, while on the older variants use it to encode both the valid channels and the channel-specific peripheral-id. On affected SoCs the target-id is always 3 bit wide, so we use these and an additional 4th bit to hold the valid state. As the older SoCs all have 4 dma channels this can live happily in an u16 element. The s3c24xx series will most likely not see any new offspring, but even if it happens any new model will probably use the newer more flexible variant of the dma controller, so this should not restrict anything in the future. Example: SDI is valid on channels 0, 2 and 3 - with varying hw request sources. For it the chansel field would look like ((BIT(3) | 1) 3 * 4) | // channel 3, with request source 1 ((BIT(3) | 2) 2 * 4) | // channel 2, with request source 2 ((BIT(3) | 2) 0 * 4) // channel 0, with request source 2 Heiko Stuebner (4): ARM: S3C24XX: number the dma clocks dmaengine: add driver for Samsung s3c24xx SoCs ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and s3c2443 ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device arch/arm/mach-s3c24xx/clock-s3c2412.c |8 +- arch/arm/mach-s3c24xx/common-s3c2443.c| 12 +- arch/arm/mach-s3c24xx/common.c| 106 +++ arch/arm/mach-s3c24xx/common.h|3 + arch/arm/mach-s3c24xx/mach-jive.c |1 + arch/arm/mach-s3c24xx/mach-smdk2413.c |1 + arch/arm/mach-s3c24xx/mach-smdk2416.c |1 + arch/arm/mach-s3c24xx/mach-smdk2443.c |1 + arch/arm/mach-s3c24xx/mach-vstms.c|1 + arch/arm/plat-samsung/devs.c |5 +- drivers/dma/Kconfig | 12 + drivers/dma/Makefile |1 + drivers/dma/s3c24xx-dma.c | 1255 + include/linux/platform_data/dma-s3c24xx.h | 43 + 14 files changed, 1439 insertions(+), 11 deletions(-) create mode 100644 drivers/dma/s3c24xx-dma.c create mode 100644 include/linux/platform_data/dma-s3c24xx.h Looks good to me, but I need ack from Vinod, dma maintainer. Vinod, if you're OK on this, please let us know so that I could take this whole series into samsung tree. Thanks, Kukjin -- 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 v4 2/3] ARM: dts: Update the status of RTC DT node of Exynos5250 SoC to okay
On 08/15/13 17:59, Tomasz Figa wrote: Hi Tushar, [...] + status = okay; }; Sometime back we had a discussion on this, the decision was to enable it in respective boards. This is not entirely true. According to ePAPR, chapter 2.3.4, the status property has a well defined meaning and it should be set to disabled when the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off). So in my understanding, you mean using okay is wrong and only disabled is used? and in board dt file? Already there are too many okay... This means that unless setup of the device is missing something (e.g. board-specific properties, like regulators or pin config) or there is a valid technical reason for disabling the device by default (e.g. it needs certain SoC pins to be properly connected to something), then such device should be okay, because it is operational. Also if we are going ahead with this, we would need to remove the corresponding status statements from board files. Yes, this is true. According to above, probably we should add disabled in board dt file? If I'm wrong, correct me. (+ dt ml) Anyway, I'm not sure how to use 'okay' and 'disabled' for status... I think, every hardware information should be defined in SoC dt file and maybe some of them could be set disabled or okay in each board dt file... Any suggestions? Thanks, Kukjin -- 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/9] ARM: dts: exynos: add support for hdmi subsystem
On 08/14/13 20:26, Tomasz Figa wrote: [...] See my comments about making common stuff for exynos5 SoCs. I agree. And please don't use title like following, 'ARM: dts: exynos: '. Because the relatively long prefix of title can cover _real_ title, So just 'ARM: dts: in exynos000' is better. Well, I tend to disagree on this. The ARM: dts:platform name: prefix is commonly used in arch/arm/boot/dts (see git log --oneline arch/arm/boot/dts). Hmm...it is not entirely true... As long as we don't cross the ~75 characters boundary in patch subject, I don't think this is any problem. Let's see. If we use the 'platform name' in prefixe for dt file, ARM: dts: exynos: add support for something or ARM: dts: universal_c210: add support for something or ARM: dts: exynos-pinctrl: add support for something ... most of them should spend over half of 75 characters as a prefix including 'add support for' in subject and in addition, there is '[PATCH v0 00/00]' in the email subject. (+ Russell) I remember there were discussions about subject and at that time the result was that keyword should be shown ahead as possible in subject. But we are still using too long word as a prefix... One more note, even my e-mail client shows just 40~50 characters for subject because of relatively not big enough resolution and pre-read window and so on ;) Kukjin -- 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: [PATCHv3 1/4] drm/exynos: add device tree support for rotator
On 08/13/13 14:12, Chanho Park wrote:
The exynos4 platform is only dt-based since 3.10, we should convert driver data
and ids to dt-based parsing methods. The rotator driver has a limit table to get
size limit of input picture. Each SoCs has slightly different limit value
compared with any others.
For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others have
8k x 8k. Another example the exynos5250 should have multiple of 2 pixel size
for its X/Y axis. Thus, we should keep different tables for each of them.
This patch also includes desciptions of each nodes for the rotator and specifies
a example how to bind it.
Signed-off-by: Chanho Parkchanho61.p...@samsung.com
Cc: Inki Daeinki@samsung.com
Inki, do you OK on this? If so, let me take this whole series into the
samsung tree.
Thanks,
Kukjin
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
.../devicetree/bindings/gpu/samsung-rotator.txt| 27 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c| 108 +++-
2 files changed, 107 insertions(+), 28 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
new file mode 100644
index 000..82cd1ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
@@ -0,0 +1,27 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be one of the following:
+ (a) samsung,exynos4210-rotator for Rotator IP in Exynos4210
+ (b) samsung,exynos4212-rotator for Rotator IP in Exynos4212/4412
+ (c) samsung,exynos5250-rotator for Rotator IP in Exynos5250
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : Interrupt specifier for rotator interrupt, according to format
+specific to interrupt parent.
+
+ - clocks : Clock specifier for rotator clock, according to generic clock
+bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
+
+ - clock-names : Names of clocks. For exynos rotator, it should be rotator.
+
+Example:
+ rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg =0x1281 0x1000;
+ interrupts =0 83 0;
+ clocks =clock 278;
+ clock-names = rotator;
+ };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 427640a..0485aea5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -632,21 +632,98 @@ static int rotator_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
return 0;
}
+static struct rot_limit_table rot_limit_tbl_4210 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_64K,
+ .max_h = SZ_64K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_16K,
+ .max_h = SZ_16K,
+ .align = 2,
+ },
+};
+
+static struct rot_limit_table rot_limit_tbl_4x12 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_32K,
+ .max_h = SZ_32K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_8K,
+ .max_h = SZ_8K,
+ .align = 2,
+ },
+};
+
+static struct rot_limit_table rot_limit_tbl_5250 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_32K,
+ .max_h = SZ_32K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_8K,
+ .max_h = SZ_8K,
+ .align = 1,
+ },
+};
+
+static const struct of_device_id exynos_rotator_match[] = {
+ {
+ .compatible = samsung,exynos4210-rotator,
+ .data =rot_limit_tbl_4210,
+ },
+ {
+ .compatible = samsung,exynos4212-rotator,
+ .data =rot_limit_tbl_4x12,
+ },
+ {
+ .compatible = samsung,exynos5250-rotator,
+ .data =rot_limit_tbl_5250,
+ },
+ {},
+};
+
static int rotator_probe(struct platform_device *pdev)
{
struct device *dev =pdev-dev;
struct rot_context *rot;
struct exynos_drm_ippdrv *ippdrv;
+ const struct of_device_id *match;
int ret;
+ if (!dev-of_node) {
+ dev_err(dev, cannot find of_node.\n);
+ return -ENODEV;
+ }
+
rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
if
Re: [PATCH] ARM: DT: Exynos: fix number of interrupt-cells in mct node
On 08/12/13 15:23, Chander Kashyap wrote:
ping
On 23 July 2013 15:17, Chander Kashyapchander.kash...@linaro.org wrote:
ping.
On 14 June 2013 20:11, Chander Kashyapchander.kash...@linaro.org wrote:
Two cells were used to specify interrupts in mct node, while second cell
always remains unused. Hence use only one cell.
Suggested by Tomasz Figa.
Signed-off-by: Chander Kashyapchander.kash...@linaro.org
---
arch/arm/boot/dts/exynos4210.dtsi | 19 +--
arch/arm/boot/dts/exynos4212.dtsi | 19 +--
arch/arm/boot/dts/exynos4412.dtsi | 23 +++
arch/arm/boot/dts/exynos5250.dtsi | 19 +--
4 files changed, 38 insertions(+), 42 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 54710de..ad50010 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -52,23 +52,22 @@
compatible = samsung,exynos4210-mct;
reg =0x1005 0x800;
interrupt-controller;
- #interrups-cells =2;
+ #interrups-cells =1;
interrupt-parent =mct_map;
- interrupts =0 0,1 0,2 0,3 0,
-4 0,5 0;
+ interrupts =0,1,2,3,4,5;
clocks =clock 3,clock 344;
clock-names = fin_pll, mct;
mct_map: mct-map {
- #interrupt-cells =2;
+ #interrupt-cells =1;
#address-cells =0;
#size-cells =0;
- interrupt-map =0x0 0gic 0 57 0,
-0x1 0gic 0 69 0,
-0x2 0combiner 12 6,
-0x3 0combiner 12 7,
-0x4 0gic 0 42 0,
-0x5 0gic 0 48 0;
+ interrupt-map =0gic 0 57 0,
+1gic 0 69 0,
+2combiner 12 6,
+3combiner 12 7,
+4gic 0 42 0,
+5gic 0 48 0;
};
};
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index c0f60f4..ba9ada1 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -39,21 +39,20 @@
compatible = samsung,exynos4412-mct;
reg =0x1005 0x800;
interrupt-controller;
- #interrups-cells =2;
+ #interrups-cells =1;
interrupt-parent =mct_map;
- interrupts =0 0,1 0,2 0,3 0,
-4 0,5 0;
+ interrupts =0,1,2,3,4,5;
mct_map: mct-map {
- #interrupt-cells =2;
+ #interrupt-cells =;
#address-cells =0;
#size-cells =0;
- interrupt-map =0x0 0gic 0 57 0,
-0x1 0combiner 12 5,
-0x2 0combiner 12 6,
-0x3 0combiner 12 7,
-0x4 0gic 1 12 0,
-0x5 0gic 1 12 0;
+ interrupt-map =0gic 0 57 0,
+1combiner 12 5,
+2combiner 12 6,
+3combiner 12 7,
+4gic 1 12 0,
+5gic 1 12 0;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 270b389..a680de7 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -39,25 +39,24 @@
compatible = samsung,exynos4412-mct;
reg =0x1005 0x800;
interrupt-controller;
- #interrups-cells =2;
+ #interrups-cells =1;
interrupt-parent =mct_map;
- interrupts =0 0,1 0,2 0,3 0,
-4 0,5 0,6 0,7 0;
+ interrupts =0,1,2,3,4,5,6,7;
clocks =clock 3,clock 344;
clock-names = fin_pll, mct;
mct_map: mct-map {
- #interrupt-cells =2;
+ #interrupt-cells =1;
#address-cells =0;
#size-cells =0;
- interrupt-map =0x0 0gic 0 57 0,
-0x1 0combiner 12 5,
-0x2 0combiner 12 6,
-0x3 0combiner 12 7,
-0x4 0gic 1 12 0,
-0x5 0gic 1 12 0,
-0x6 0gic 1 12 0,
-0x7 0gic 1 12 0;
+ interrupt-map =0gic 0 57 0,
+1combiner 12 5,
+2combiner 12 6,
+3combiner 12 7,
+4gic 1 12 0,
+5gic 1 12 0,
+6gic 1 12 0,
+7gic 1 12 0;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index a7cf3f5..4e633ef 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -94,23 +94,22 @@
compatible = samsung,exynos4210-mct;
reg =0x101C 0x800;
interrupt-controller;
- #interrups-cells =2;
+ #interrups-cells =1;
interrupt-parent =mct_map;
- interrupts =0 0,1 0,2 0,3 0,
-4 0,5 0;
+ interrupts =0,1,2,3,4,5;
clocks =clock 1,clock 335;
clock-names = fin_pll, mct;
mct_map: mct-map {
- #interrupt-cells =2;
+
Re: [PATCH] ARM: dts: Add secure-firmware boot support for OrigenQaud board
On 08/12/13 14:16, Tushar Behera wrote:
On 23 July 2013 11:52, Tushar Beheratushar.beh...@linaro.org wrote:
OrigenQuad board boots with secure firmware support. Enable support for
reading smc commands.
The binding has been updated as per the documentation provided in
Documentation/devicetree/bindings/arm/samsung-boards.txt.
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/boot/dts/exynos4412-origen.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index 7993641..8768b03 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -27,6 +27,11 @@
bootargs =console=ttySAC2,115200;
};
+ firmware@0203F000 {
+ compatible = samsung,secure-firmware;
+ reg =0x0203F000 0x1000;
+ };
+
mmc_reg: voltage-regulator {
compatible = regulator-fixed;
regulator-name = VMEM_VDD_2.8V;
--
1.7.9.5
Any comments on this?
Applied, thanks,
Kukjin
--
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/2] ARM: dts: Enable USB hub on Arndale
On 08/15/13 08:27, Mark Brown wrote:
From: Mark Brownbroo...@linaro.org
The Arndale has a SMSC USB3503 connected in hardware only mode like a PHY,
support it using the usb-nop-xceiv binding.
Note that due to a regrettable decision to use a regulator to represent
the reset signal this uses a fixed voltage regulator to do that, there
is a plan to use the reset controller binding once that is merged so it
does not seem worthwhile to fix the usb-nop-xceiv driver at this point.
Signed-off-by: Mark Brownbroo...@linaro.org
Tested-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/boot/dts/exynos5250-arndale.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 96d528d..2428ffd 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -539,4 +539,18 @@
rtc {
status = okay;
};
+
+ usb_hub_bus {
+ compatible = simple-bus;
+ #address-cells =1;
+ #size-cells =0;
+
+ // SMSC USB3503 connected in hardware only mode as a PHY
+ usb_hub: usb_hub {
+ compatible = smsc,usb3503a;
+
+ reset-gpios =gpx3 5 1;
+ connect-gpios =gpd1 7 1;
+ };
+ };
};
Applied, thanks.
Kukjin
--
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/4] DT/ARCH updates for MFC
On 08/14/13 20:41, Arun Kumar K wrote: The patch series updates the DT nodes of MFC in Exynos4, Exynos 5250 and creates node in 5420. The memory reservation patch for MFC v7 firmware is omitted in this series as its no longer needed after the new CMA DT framework by Marek Szyprowski. Changes from v2: - Removed register and interrupt properties from common exynos5.dtsi file as per Kukjin Kim's suggestion. - Dropped v7 memory reservation patch Changes from v1: - Made status disabled in dtsi and enable in dts as suggested by Sachin Kamat. - Moved common properties to exynos5.dtsi as suggested by Chander. - Updated binding documentation for special clk removal - Updated exynos4 dtsi Arun Kumar K (4): ARM: dts: Update clocks entry in MFC binding documentation ARM: dts: Remove unsused MFC clock from exynos4 ARM: dts: Update 5250 MFC node ARM: dts: Add MFC node for exynos 5420 .../devicetree/bindings/media/s5p-mfc.txt | 10 +- arch/arm/boot/dts/exynos4.dtsi |4 ++-- arch/arm/boot/dts/exynos5250.dtsi |2 ++ arch/arm/boot/dts/exynos5420.dtsi |8 4 files changed, 17 insertions(+), 7 deletions(-) Applied this whole series, thanks. Kukjin -- 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/4] ARM: dts: Correct the /include entry on exynos5420 dtsi file
On 07/10/13 21:11, Padmavathi Venna wrote:
This patch corrects the /include to #include on exynos5420
Signed-off-by: Padmavathi Vennapadm...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..da55160 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -14,7 +14,7 @@
*/
#include exynos5.dtsi
-/include/ exynos5420-pinctrl.dtsi
+#include exynos5420-pinctrl.dtsi
/ {
compatible = samsung,exynos5420;
Applied, thanks.
- Kukjin
--
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 4/4] ARM: dts: exynos5420: add audio clock controller
On 07/10/13 21:11, Padmavathi Venna wrote:
From: Andrew Brestickerabres...@chromium.org
This adds device-tree bindings for the audio subsystem clock controller
on Exynos 5420.
Signed-off-by: Andrew Brestickerabres...@chromium.org
Reviewed-on: https://gerrit.chromium.org/gerrit/57712
Reviewed-by: Simon Glasss...@chromium.org
Signed-off-by: Padmavathi Vennapadm...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index da55160..a84f5f1 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -15,6 +15,9 @@
#include exynos5.dtsi
#include exynos5420-pinctrl.dtsi
+
+#includedt-bindings/clk/exynos-audss-clk.h
+
/ {
compatible = samsung,exynos5420;
@@ -65,6 +68,14 @@
#clock-cells =1;
};
+ clock_audss: audss-clock-controller@381 {
+ compatible = samsung,exynos5420-audss-clock;
+ reg =0x0381 0x0C;
+ #clock-cells =1;
+ clocks =clock 148;
+ clock-names = sclk_audio;
+ };
+
mct@101C {
compatible = samsung,exynos4210-mct;
reg =0x101C 0x800;
Applied, thanks.
- Kukjin
--
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: EXYNOS: always enable PM domains support for EXYNOS4x12
On 08/09/13 23:53, Tomasz Figa wrote: Hi Bart, On Friday 09 of August 2013 13:56:05 Bartlomiej Zolnierkiewicz wrote: Currently PM domains support will be enabled for EXYNOS4x12 SoCs only if EXYNOS4210 SoC or EXYNOS5250 SoC support is also enabled. Fix it by explicitly selecting PM domains support (if PM support is enabled) by SOC_EXYNOS4212 and SOC_EXYNOS4412 config options. Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: b/arch/arm/mach-exynos/Kconfig === --- a/arch/arm/mach-exynos/Kconfig 2013-08-08 14:36:02.0 +0200 +++ b/arch/arm/mach-exynos/Kconfig 2013-08-08 14:38:48.967486318 +0200 @@ -52,6 +52,7 @@ config SOC_EXYNOS4212 depends on ARCH_EXYNOS4 select ARCH_HAS_BANDGAP select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM select S5P_PM if PM select S5P_SLEEP if PM select SAMSUNG_DMADEV @@ -64,6 +65,7 @@ config SOC_EXYNOS4412 depends on ARCH_EXYNOS4 select ARCH_HAS_BANDGAP select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM select SAMSUNG_DMADEV help Enable EXYNOS4412 SoC support Acked-by: Tomasz Figat.f...@samsung.com Applied, thanks. - Kukjin -- 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 RESEND] ARM: dts: Add USB host node for Exynos4
On 08/06/13 03:09, Dongjin Kim wrote:
This patch adds EHCI and OHCI host device nodes for Exynos4.
CC: Jingoo Hanjg1@samsung.com
Signed-off-by: Dongjin Kimtobet...@gmail.com
---
arch/arm/boot/dts/exynos4.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..cbe5219 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -155,6 +155,24 @@
status = disabled;
};
+ ehci@1258 {
+ compatible = samsung,exynos4210-ehci;
+ reg =0x1258 0x100;
+ interrupts =0 70 0;
+ clocks =clock 304;
+ clock-names = usbhost;
+ status = disabled;
+ };
+
+ ohci@1259 {
+ compatible = samsung,exynos4210-ohci;
+ reg =0x1259 0x100;
+ interrupts =0 70 0;
+ clocks =clock 304;
+ clock-names = usbhost;
+ status = disabled;
+ };
+
mfc: codec@1340 {
compatible = samsung,mfc-v5;
reg =0x1340 0x1;
Applied, thanks.
- Kukjin
--
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] s5p-jpeg: Add initial device tree support for S5PV210/Exynos4210 SoCs
This patch enables the JPEG codec on S5PV210 and Exynos4210 SoCs. There are
some differences in newer versions of the JPEG codec IP on SoCs like Exynos4x12
and Exynos5 series and support for them will be added in subsequent patches.
Cc: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../bindings/media/exynos-jpeg-codec.txt | 11 +++
drivers/media/platform/s5p-jpeg/jpeg-core.c| 12 +++-
2 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
new file mode 100644
index 000..937b755
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -0,0 +1,11 @@
+Samsung S5P/EXYNOS SoC series JPEG codec
+
+Required properties:
+
+- compatible : should be one of:
+ samsung,s5pv210-jpeg, samsung,exynos4210-jpeg;
+- reg : address and length of the JPEG codec IP register set;
+- interrupts : specifies the JPEG codec IP interrupt;
+- clocks : should contain the JPEG codec IP gate clock specifier, from
the
+ common clock bindings;
+- clock-names : should contain jpeg entry.
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 15d2396..88c5beb 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/slab.h
@@ -1513,10 +1514,20 @@ static const struct dev_pm_ops s5p_jpeg_pm_ops = {
.runtime_resume = s5p_jpeg_runtime_resume,
};
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_jpeg_of_match[] = {
+ { .compatible = samsung,s5pv210-jpeg },
+ { .compatible = samsung,exynos4210-jpeg },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, s5p_jpeg_of_match);
+#endif
+
static struct platform_driver s5p_jpeg_driver = {
.probe = s5p_jpeg_probe,
.remove = s5p_jpeg_remove,
.driver = {
+ .of_match_table = of_match_ptr(s5p_jpeg_of_match),
.owner = THIS_MODULE,
.name = S5P_JPEG_M2M_NAME,
.pm = s5p_jpeg_pm_ops,
@@ -1528,4 +1539,3 @@ module_platform_driver(s5p_jpeg_driver);
MODULE_AUTHOR(Andrzej Pietrasiewicz andrze...@samsung.com);
MODULE_DESCRIPTION(Samsung JPEG codec driver);
MODULE_LICENSE(GPL);
-
--
1.7.4.1
--
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 RESEND] ARM: plat-samsung: Fix switching FIFO in arch_enable_uart_fifo function
On 07/03/13 04:16, Alexander Shiyan wrote: When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should enable FIFO but actually switch command is missing in the code. This patch adds this switching. Signed-off-by: Alexander Shiyanshc_w...@mail.ru --- arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h b/arch/arm/plat-samsung/include/plat/uncompress.h index 4afc32f..f48dc0a 100644 --- a/arch/arm/plat-samsung/include/plat/uncompress.h +++ b/arch/arm/plat-samsung/include/plat/uncompress.h @@ -145,6 +145,8 @@ static inline void arch_enable_uart_fifo(void) if (!(fifocon S3C2410_UFCON_RESETBOTH)) break; } + + uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE); } } #else Sorry for late response, applied. Thanks, Kukjin -- 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: Remove unnecessary exynos4_default_sdhci*()
On 07/15/13 09:21, Jingoo Han wrote:
Commit 17397a2(ARM: EXYNOS: Remove platform device initialization)
removes calling exynos4_default_sdhci*() functions; thus, these are
not necessary any more.
Signed-off-by: Jingoo Hanjg1@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h | 38
1 file changed, 38 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-samsung/include/plat/sdhci.h
index ce1d0f7..bf65021 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -260,44 +260,6 @@ static inline void s5pv210_default_sdhci3(void) { }
#endif /* CONFIG_S5PV210_SETUP_SDHCI */
-/* EXYNOS4 SDHCI setup */
-#ifdef CONFIG_EXYNOS4_SETUP_SDHCI
-static inline void exynos4_default_sdhci0(void)
-{
-#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.cfg_gpio = exynos4_setup_sdhci0_cfg_gpio;
-#endif
-}
-
-static inline void exynos4_default_sdhci1(void)
-{
-#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.cfg_gpio = exynos4_setup_sdhci1_cfg_gpio;
-#endif
-}
-
-static inline void exynos4_default_sdhci2(void)
-{
-#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.cfg_gpio = exynos4_setup_sdhci2_cfg_gpio;
-#endif
-}
-
-static inline void exynos4_default_sdhci3(void)
-{
-#ifdef CONFIG_S3C_DEV_HSMMC3
- s3c_hsmmc3_def_platdata.cfg_gpio = exynos4_setup_sdhci3_cfg_gpio;
-#endif
-}
-
-#else
-static inline void exynos4_default_sdhci0(void) { }
-static inline void exynos4_default_sdhci1(void) { }
-static inline void exynos4_default_sdhci2(void) { }
-static inline void exynos4_default_sdhci3(void) { }
-
-#endif /* CONFIG_EXYNOS4_SETUP_SDHCI */
-
static inline void s3c_sdhci_setname(int id, char *name)
{
switch (id) {
Looks good to me, applied.
Thanks,
Kukjin
--
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
[GIT PULL 0/2] Samsung pull-request for v3.12
Hi Arnd and Olof, Here is Samsung cleanup and Exynos DT stuff for v3.12. They include non-dt cleanup and unused codes, and add exynos4412-trats2 board and update Arndale board, exynos5420 and exynos4 series. Just note, I'm holding on defconfig update branch because of concern for exynos5440_defconfig and I'm waiting for Mike's clk update for s3c64xx common clk and addressing comments for several DT patches. If any problems, please let me know. Thanks, Kukjin -- 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
[GIT PULL 2/2] Samsung Exynos DT for v3.12
The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-1 for you to fetch changes up to 6f9d02a056fff8e965da0f940a09d4c39a4fe80a: ARM: dts: Add USB host node for Exynos4 (2013-08-19 05:07:17 +0900) Samsung Exynos DT updates for v3.12 - update codec, pmic, usb hub for Arndale - add exynos4412-trats 2 board dt - update camera, spi, sensor for Trats2 - update fimc, sensor for Trats - add support tmu for exynos5440 - add support g2d for exynos5250 - correct camera pinctrl for exynos4x12 - add support camera subsystem for exynos4 - add support basic pm domain, fimd, dp for exynos5420 - add support secure-firmware for OrigenQuad - update mfc and add support mfc for exynos5420 - add usb host node for exynos4 Amit Daniel Kachhap (1): ARM: dts: Add device tree node for exynos5440 TMU controller Andrew Bresticker (1): ARM: dts: add audio clock controller for exynos5420 Andrzej Hajda (3): ARM: dts: Add SPI1 controller and s5c73m3 sensor node for TRATS2 ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes ARM: dts: Add S5K5BA sensor regulator definitions for Trats board Arun Kumar K (4): ARM: dts: Update clocks entry in MFC binding documentation ARM: dts: Remove unsused MFC clock from exynos4 ARM: dts: Update 5250 MFC node ARM: dts: Add MFC node for exynos 5420 Dongjin Kim (1): ARM: dts: Add USB host node for Exynos4 Jacek Anaszewski (1): ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board Kukjin Kim (1): ARM: dts: re-ordering exynos dtbs in Makefile Mark Brown (6): ARM: dts: Hook up IRQ for PMIC on Arndale ARM: dts: Put Arndale fixed voltage regulators on a simple-bus ARM: dts: Hook up supplies for Arndale S5M8767 ARM: dts: Add WM1811A audio CODEC to Arndale bindings ARM: dts: Enable USB hub on Arndale ARM: dts: Hook up internal PHY on Arndale Padmavathi Venna (1): ARM: dts: Correct the /include entry on exynos5420 dtsi file Sachin Kamat (1): ARM: dts: Add G2D support to exynos5250 Sylwester Nawrocki (9): ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals ARM: dts: Add ISP power domain node for Exynos4x12 ARM: dts: Use generic DMA bindings for Exynos4 SPI devices ARM: dts: Add camera subsystem device nodes to exynos4.dtsi ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board ARM: dts: Add camera device nodes for Exynos4210 SoCs ARM: dts: Add FIMC nodes for Exynos4210 Trats board Tomasz Figa (1): ARM: dts: Add basic dts for Exynos4412-based Trats 2 board Tushar Behera (1): ARM: dts: Add secure-firmware boot support for OrigenQaud board Vikas Sajjan (6): ARM: dts: Move display-timing information inside FIMD DT node for exynos5250 ARM: dts: Update FIMD DT node for Exynos5 SoCs ARM: dts: Add FIMD DT node to exynos5420 DTS files ARM: dts: Update DP controller DT Node for Exynos5 based SoCs ARM: dts: Add DP controller DT node to exynos5420 SoC ARM: dts: Add pin state information for DP HPD support to Exynos5420 Yadwinder Singh Brar (1): ARM: dts: Add basic PM domains for EXYNOS5420 .../devicetree/bindings/media/s5p-mfc.txt | 10 +- arch/arm/boot/dts/Makefile |5 +- arch/arm/boot/dts/exynos4.dtsi | 122 - arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 23 + arch/arm/boot/dts/exynos4210-trats.dts | 100 +++- arch/arm/boot/dts/exynos4210.dtsi | 30 + arch/arm/boot/dts/exynos4412-origen.dts|5 + arch/arm/boot/dts/exynos4412-trats2.dts| 579 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 61 ++- arch/arm/boot/dts/exynos4x12.dtsi | 103 arch/arm/boot/dts/exynos5.dtsi | 19 + arch/arm/boot/dts/exynos5250-arndale.dts | 105 +++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 32 +- arch/arm/boot/dts/exynos5250.dtsi | 38 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts | 31 ++ arch/arm/boot/dts/exynos5420.dtsi | 75 ++- arch/arm/boot/dts/exynos5440.dtsi | 27 + 18 files changed, 1288 insertions(+), 84 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4412-trats2.dts -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a
[GIT PULL 1/2] Samsung cleanup for v3.12
The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cleanup-1 for you to fetch changes up to 8c3736e20ee387acefffdfcac560ea23ee6fd4d8: ARM: SAMSUNG: Remove unnecessary exynos4_default_sdhci*() (2013-08-19 05:23:32 +0900) samsung cleanup for v3.12 - cleanup non-dt stuff in exynos - remove 0x from exynos dt files - remove unused codes Jingoo Han (1): ARM: SAMSUNG: Remove unnecessary exynos4_default_sdhci*() Kukjin Kim (1): irqchip: exynos: cleanup non-DT stuff in exynos-combiner Lee Jones (5): ARM: dts: Remove '0x's from Exynos4210 DTSI file ARM: dts: Remove '0x's from Exynos4x12 DTSI file ARM: dts: Remove '0x's from Exynos5250 DTS file ARM: dts: Remove '0x's from Exynos5420 DTS file ARM: dts: Remove '0x's from Exynos5440 DTS file Sachin Kamat (1): ARM: EXYNOS: Cleanup common.h file arch/arm/boot/dts/exynos4210.dtsi |2 +- arch/arm/boot/dts/exynos4x12.dtsi |2 +- arch/arm/boot/dts/exynos5250.dtsi | 14 - arch/arm/boot/dts/exynos5420.dtsi |2 +- arch/arm/boot/dts/exynos5440.dtsi |2 +- arch/arm/mach-exynos/common.h | 43 --- arch/arm/plat-samsung/include/plat/sdhci.h | 38 drivers/irqchip/exynos-combiner.c | 44 +--- 8 files changed, 12 insertions(+), 135 deletions(-) -- 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: Cleanup error code in **_usb_get_phy_**() APIs
Hi,
On Thu, Aug 8, 2013 at 12:05 AM, Julius Werner jwer...@chromium.org wrote:
@@ -94,11 +94,11 @@ static int devm_usb_phy_match(struct device *dev, void
*res, void *match_data)
*/
struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
{
- struct usb_phy **ptr, *phy;
+ struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
This looks a little roundabout, don't you think? Why don't you just
directly have 'return ERR_PTR(-ENOMEM)' down there where you put 'goto
err0'?
Ok, will change this.
ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
if (!ptr)
- return NULL;
+ goto err0;
phy = usb_get_phy(type);
if (!IS_ERR(phy)) {
@@ -107,6 +107,7 @@ struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type)
} else
devres_free(ptr);
+err0:
return phy;
}
EXPORT_SYMBOL_GPL(devm_usb_get_phy);
struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
{
- struct usb_phy **ptr, *phy;
+ struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
Same here
will change this too.
ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
if (!ptr)
- return NULL;
+ goto err0;
phy = usb_get_phy_dev(dev, index);
if (!IS_ERR(phy)) {
@@ -267,6 +268,7 @@ struct usb_phy *devm_usb_get_phy_dev(struct device *dev,
u8 index)
} else
devres_free(ptr);
+err0:
return phy;
}
EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
@@ -142,7 +142,7 @@ extern void usb_remove_phy(struct usb_phy *);
/* helpers for direct access thru low-level io interface */
static inline int usb_phy_io_read(struct usb_phy *x, u32 reg)
{
- if (x-io_ops x-io_ops-read)
+ if (!IS_ERR(x) x-io_ops x-io_ops-read)
I liked the ones where we had IS_ERR_OR_NULL() here (and in all the
ones below)... you sometimes have to handle PHYs in
platform-independent code where you don't want to worry about if this
platform actually has a PHY driver there or not. Any reason you
changed that?
The **get_phy_*() APIs never return a NULL pointer now, do we still
need to handle that in that case.
Or are we assuming that code will use these phy operations without
getting a phy in the first place ?
return x-io_ops-read(x, reg);
return -EINVAL;
@@ -150,7 +150,7 @@ static inline int usb_phy_io_read(struct usb_phy *x, u32
reg)
static inline int usb_phy_io_write(struct usb_phy *x, u32 val, u32 reg)
{
- if (x-io_ops x-io_ops-write)
+ if (!IS_ERR(x) x-io_ops x-io_ops-write)
return x-io_ops-write(x, val, reg);
return -EINVAL;
@@ -159,7 +159,7 @@ static inline int usb_phy_io_write(struct usb_phy *x,
u32 val, u32 reg)
static inline int
usb_phy_init(struct usb_phy *x)
{
- if (x-init)
+ if (!IS_ERR(x) x-init)
return x-init(x);
return 0;
@@ -168,26 +168,27 @@ usb_phy_init(struct usb_phy *x)
static inline void
usb_phy_shutdown(struct usb_phy *x)
{
- if (x-shutdown)
+ if (!IS_ERR(x) x-shutdown)
x-shutdown(x);
}
static inline int
usb_phy_vbus_on(struct usb_phy *x)
{
- if (!x-set_vbus)
- return 0;
+ if (!IS_ERR(x) x-set_vbus)
+ return x-set_vbus(x, true);
- return x-set_vbus(x, true);
+ return 0;
}
static inline int
usb_phy_vbus_off(struct usb_phy *x)
{
- if (!x-set_vbus)
- return 0;
+ if (!IS_ERR(x) x-set_vbus)
+ return x-set_vbus(x, false);
+
+ return 0;
- return x-set_vbus(x, false);
}
/* for usb host and peripheral controller drivers */
@@ -249,8 +250,9 @@ static inline int usb_bind_phy(const char *dev_name, u8
index,
static inline int
usb_phy_set_power(struct usb_phy *x, unsigned mA)
{
- if (x x-set_power)
+ if (!IS_ERR(x) x-set_power)
return x-set_power(x, mA);
+
return 0;
}
@@ -258,28 +260,28 @@ usb_phy_set_power(struct usb_phy *x, unsigned mA)
static inline int
usb_phy_set_suspend(struct usb_phy *x, int suspend)
{
- if (x-set_suspend != NULL)
+ if (!IS_ERR(x) x-set_suspend != NULL)
return x-set_suspend(x, suspend);
- else
- return 0;
+
+ return 0;
}
static inline int
usb_phy_notify_connect(struct usb_phy *x, enum usb_device_speed speed)
{
- if (x-notify_connect)
+ if (!IS_ERR(x) x-notify_connect)
return x-notify_connect(x, speed);
- else
- return 0;
+
+ return 0;
}
static inline int
usb_phy_notify_disconnect(struct usb_phy *x, enum usb_device_speed speed)
{
- if (x-notify_disconnect)
+ if (!IS_ERR(x) x-notify_disconnect)
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Felipe,
ping..
On Wednesday 14 August 2013 08:35 PM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well,
Re: [PATCH v2 2/4] dmaengine: add driver for Samsung s3c24xx SoCs
On Wed, Aug 14, 2013 at 02:00:25PM +0200, Heiko Stübner wrote:
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
with numerous virtual channels being mapped to a lot less physical ones.
The driver therefore borrows a lot from the amba-pl08x driver in this
regard. Functionality-wise the driver gains a memcpy ability in addition
to the slave_sg one.
If that is the case why cant we have this driver supported from pl08x driver? If
the delta is only mapping then can that be seprated or both mapping hanlded?
Maybe you and Linus have already though about that?
The driver supports both the method for requesting the peripheral used
by SoCs before the S3C2443 and the different method for S3C2443 and later.
On earlier SoCs the hardware channels usable for specific peripherals is
constrainted while on later SoCs all channels can be used for any peripheral.
Tested on a s3c2416-based board, memcpy using the dmatest module and
slave_sg partially using the spi-s3c64xx driver.
Signed-off-by: Heiko Stuebner he...@sntech.de
+#define DISRC(0x00)
+#define DISRCC (0x04)
+#define DISRCC_INC_INCREMENT (0 0)
+#define DISRCC_INC_FIXED (1 0)
+#define DISRCC_LOC_AHB (0 1)
+#define DISRCC_LOC_APB (1 1)
+
+#define DIDST(0x08)
+#define DIDSTC (0x0C)
+#define DIDSTC_INC_INCREMENT (0 0)
+#define DIDSTC_INC_FIXED (1 0)
+#define DIDSTC_LOC_AHB (0 1)
+#define DIDSTC_LOC_APB (1 1)
+#define DIDSTC_INT_TC0 (0 2)
+#define DIDSTC_INT_RELOAD(1 2)
+
+#define DCON (0x10)
+
+#define DCON_TC_MASK 0xf
+#define DCON_DSZ_BYTE(0 20)
+#define DCON_DSZ_HALFWORD(1 20)
+#define DCON_DSZ_WORD(2 20)
+#define DCON_DSZ_MASK(3 20)
+#define DCON_DSZ_SHIFT 20
+#define DCON_AUTORELOAD (0 22)
+#define DCON_NORELOAD(1 22)
+#define DCON_HWTRIG (1 23)
+#define DCON_HWSRC_SHIFT 24
+#define DCON_SERV_SINGLE (0 27)
+#define DCON_SERV_WHOLE (1 27)
+#define DCON_TSZ_UNIT(0 28)
+#define DCON_TSZ_BURST4 (1 28)
+#define DCON_INT (1 29)
+#define DCON_SYNC_PCLK (0 30)
+#define DCON_SYNC_HCLK (1 30)
+#define DCON_DEMAND (0 31)
+#define DCON_HANDSHAKE (1 31)
+
+#define DSTAT(0x14)
+#define DSTAT_STAT_BUSY (1 20)
+#define DSTAT_CURRTC_MASK0xf
+
+#define DMASKTRIG(0x20)
+#define DMASKTRIG_STOP (1 2)
+#define DMASKTRIG_ON (1 1)
+#define DMASKTRIG_SWTRIG (1 0)
+
+#define DMAREQSEL(0x24)
+#define DMAREQSEL_HW (1 0)
This is proper namespacing...
+static int s3c24xx_dma_set_runtime_config(struct s3c24xx_dma_chan *s3cchan,
+ struct dma_slave_config *config)
+{
+ if (!s3cchan-slave)
+ return -EINVAL;
+
+ /* Reject definitely invalid configurations */
+ if (config-src_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES ||
+ config-dst_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES)
+ return -EINVAL;
+
+ s3cchan-cfg = *config;
you are takinga ref to client pointer without a clue on when that would be
freed. I dont think its a good idea!
+static irqreturn_t s3c24xx_dma_irq(int irq, void *data)
+{
+ struct s3c24xx_dma_phy *phy = data;
+ struct s3c24xx_dma_chan *s3cchan = phy-serving;
+ struct s3c24xx_txd *txd;
+
+ dev_dbg(phy-host-pdev-dev, interrupt on channel %d\n, phy-id);
+
+ if (!s3cchan) {
+ dev_err(phy-host-pdev-dev, interrupt on unused channel
%d\n,
+ phy-id);
+ return IRQ_NONE;
hmmm, these channles belong to you. So if one of them is behvaing badly, then
not handling the interrupt will make things worse...
~Vinod
--
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
