Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
On Thu, Aug 20, 2015 at 12:31:44PM +0530, Rameshwar Sahu wrote:
Hi Vinod,
On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
+ nents = sg_nents(req-src);
+ sg_count = dma_map_sg(dev, req-src, nents, DMA_TO_DEVICE);
+ if (!sg_count) {
+ dev_err(dev, Failed to map src sg);
+ return -ENOMEM;
mapping error shouldn't be no mem error
Okay, I guess then -EIO will be fine here??
yes better
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
On Tue, Aug 18, 2015 at 2:55 PM, Viet Nga Dao vn...@altera.com wrote: -Original Message- From: ma...@denx.de Sent: Tuesday, August 18, 2015 9:33 AM To: Brian Norris Cc: linux-...@lists.infradead.org; Viet Nga Dao; devicetree@vger.kernel.org; Rafa?? Mi??ecki; linux-ker...@vger.kernel.org; David Woodhouse; Graham Moore Subject: Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: I'm not very helpful here, so hopefully Viet can be of more use: Yup :) On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: Also, I cannot find any documentation for this IP block even if I search through Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/litera ture/ hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. You can find the document at here (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_embedded_ip.pdf) Chapter 42.Page 407. For the soft IP issue, i've requested hardware engineer to come out the solution. So in the mean way, our driver will NOT support Micron flashes until hardware fix is completed. Hence, i just submitted version 5 for this driver with eliminating micron device support. Hope this version will get ACKed by you. Thanks, Viet Nga -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
On Thursday, August 20, 2015 at 09:37:33 AM, Viet Nga Dao wrote: Hi, Hi, On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: I'm not very helpful here, so hopefully Viet can be of more use: Yup :) On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: Also, I cannot find any documentation for this IP block even if I search through Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/litera ture/ hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. You can find the document at here (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literatu re/ug/ug_embedded_ip.pdf) Chapter 42.Page 407. For the soft IP issue, i've requested hardware engineer to come out the solution. That's good :) So in the mean way, our driver will NOT support Micron flashes until hardware fix is completed. This doesn't answer my question, so let me reiterate. Is this controller only Soft IP (as in, FPGA core) or is this controller shipping in some chip as Hard IP (as in, piece of silicon) ? Hence, i just submitted version 5 for this driver with eliminating micron device support. Hope this version will get ACKed by you. We'll see. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe devicetree 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 05/14] drm: bridge/analogix_dp: fix link_rate lane_count bug
Hi Jingoo,
On 08/20/2015 02:22 AM, Jingoo Han wrote:
On 2015. 8. 19., at PM 11:50, Yakir Yang y...@rock-chips.com wrote:
link_rate and lane_count already configed in analogix_dp_set_link_train(),
s/configed/configured
Also, the commit name such as fix ... bug is not good.
How about following?
drm: bridge/analogix_dp: remove duplicate configuration of link rate and link
count
Thanks, done, it's more readable.
- Yakir
Best regards,
Jingoo Han
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang y...@rock-chips.com
---
Changes in v3:
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
the DT property value directly, but we can take those as hardware limite.
For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
so DT property would like link-rate = 0x0a lane-count = 4.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 16
drivers/gpu/drm/bridge/analogix_dp_core.h | 9 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 480cc13..1778e0a 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+ * For DP rev.1.2, Maximum link rate of Main Link lanes
+ * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, data);
*bandwidth = data;
@@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, dp-link_train.lane_count);
if ((dp-link_train.link_rate != LINK_RATE_1_62GBPS)
-(dp-link_train.link_rate != LINK_RATE_2_70GBPS)) {
+(dp-link_train.link_rate != LINK_RATE_2_70GBPS)
+(dp-link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp-dev, Rx Max Link Rate is abnormal :%x !\n,
dp-link_train.link_rate);
dp-link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
-ret = analogix_dp_set_link_train(dp, dp-video_info-lane_count,
- dp-video_info-link_rate);
+ret = analogix_dp_set_link_train(dp, dp-video_info-max_lane_count,
+ dp-video_info-max_link_rate);
if (ret) {
dev_err(dp-dev, unable to do link train\n);
return;
@@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
-analogix_dp_set_lane_count(dp, dp-video_info-lane_count);
-analogix_dp_set_link_bandwidth(dp, dp-video_info-link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
@@ -1198,13 +1198,13 @@ static struct video_info
*analogix_dp_dt_parse_pdata(struct device *dev)
}
if (of_property_read_u32(dp_node, analogix,link-rate,
- dp_video_config-link_rate)) {
+ dp_video_config-max_link_rate)) {
dev_err(dev, failed to get link-rate\n);
return ERR_PTR(-EINVAL);
}
if (of_property_read_u32(dp_node, analogix,lane-count,
- dp_video_config-lane_count)) {
+ dp_video_config-max_lane_count)) {
dev_err(dev, failed to get lane-count\n);
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix_dp_core.h
index 2cefde9..941b34f 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP 5
enum link_rate_type {
-LINK_RATE_1_62GBPS = 0x06,
-LINK_RATE_2_70GBPS = 0x0a
+LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
};
enum link_lane_count_type {
@@ -128,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
-enum link_rate_type link_rate;
-enum link_lane_count_type lane_count;
+enum link_rate_type max_link_rate;
+enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 3/9] mips: pistachio_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com Acked-by: Govindraj Raja govindraj.r...@imgtec.com Acked-by: Ralf Baechle r...@linux-mips.org --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/mips/configs/pistachio_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/configs/pistachio_defconfig b/arch/mips/configs/pistachio_defconfig index 1646cce..013c62c 100644 --- a/arch/mips/configs/pistachio_defconfig +++ b/arch/mips/configs/pistachio_defconfig @@ -257,7 +257,6 @@ CONFIG_MMC=y CONFIG_MMC_BLOCK_MINORS=16 CONFIG_MMC_TEST=m CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_RTC_CLASS=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
On Thu, Aug 20, 2015 at 4:52 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, August 20, 2015 at 10:13:30 AM, Nga Chi wrote:
On Thu, Aug 20, 2015 at 4:03 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, August 20, 2015 at 08:55:05 AM, vn...@altera.com wrote:
From: VIET NGA DAO vn...@altera.com
Altera Quad SPI Controller is a soft IP which enables access to
Altera EPCS and EPCQ flash chips. This patch adds driver
for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v5:
- Remove Micron support
- Add multiple flashes probe failure handle
v4:
- Add more flash devices support ( EPCQL and Micron)
- Remove redundant messages
- Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
- Replace get_flash_name to altera_quadspi_scan
- Remove clk related parts
- Remove altera_quadspi_plat
- Change device tree reg name and remove opcode-id
v3:
- Change altera_epcq driver name to altera_quadspi for more generic name
- Implement flash name searching in altera_quadspi.c instead of spi-nor
- Edit the altra quadspi info table in spi-nor
- Remove wait_til_ready in all read,write, erase, lock, unlock functions
- Merge .h and .c into 1 file
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
drivers/mtd/spi-nor/Kconfig|8 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera-quadspi.c | 557
drivers/mtd/spi-nor/spi-nor.c
|
18 +
5 files changed, 629 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mtd/altera-quadspi.txt create mode
100644 drivers/mtd/spi-nor/altera-quadspi.c
diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt new file mode
100644
index 000..e1bcf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
@@ -0,0 +1,45 @@
+* MTD Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be altr,quadspi-1.0
+- reg: Address and length of the register set for the device. It
contains + the information of registers in the same order as described
by reg-names +- reg-names: Should contain the reg names
+ avl_csr: Should contain the register configuration base address
+ avl_mem: Should contain the data base address
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following
fields: + - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512,
epcq1024 + 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to
/mtd/partition.txt +
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw
data; + reg = 0x0
0x100; + };
+ partition@100 {
+ /* 16 MB for jffs2 data.
*/ + label = EPCQ Flash 0
JFFS 2; + reg = 0x100
0x100; + };
IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).
+ };
+ }; //end quadspi@0x180014a0 (quadspi_controller_0)
Remove this incorrect comment.
[...]
Do you mean the partition part below should not be in example?
partition@0 {
/* 16 MB for raw data. */
label = EPCQ
Re: [PATCH v3 0/8] ARM: sunxi: Add Reduced Serial Bus support
On Thu, Aug 20, 2015 at 09:59:27AM +0800, Chen-Yu Tsai wrote: On Thu, Aug 20, 2015 at 12:32 AM, Mark Brown broo...@kernel.org wrote: This is flagged as something that is specific to the Allwinner SoCs. Why add generic regmap support rather than just implement the regmap reg_read() and reg_write() in a regmap in the controller driver? Are there expected to be other controller drivers from other vendors? I don't expect there to be any other controller drivers. And it seems at least some of the devices are dual interface (I2C/RSB). Though I don't see how its connected to the generic regmap support. Regmap is for device drivers connected to the RSB bus, not the bus controller itself. The point here is that you can use regmap for a custom controller without having to implement a bus, to repeat what I said: | Why add generic regmap support rather than just implement the regmap | reg_read() and reg_write() in a regmap in the controller driver? Are I could throw all the RSB-related stuff together, presumably under drivers/soc/sunxi/rsb, though that doesn't help the fact that common regmap code would be better than scattering regmap_* in various mfd drivers. If there is only one controller driver you just have a single call into that driver in the client device which gives you the same level of shared code, having a wrapper layer in regmap that puts regmap_ functions around the equivalent controller specific functions isn't really adding a huge amount. It's a similar thing to the way we just reuse the platform bus for basic buses rather than copying it to make new bus types, we don't need to create lots of new boilerplate regmap types that are just really basic wrappers. There are a lot of these custom buses that people have. signature.asc Description: Digital signature
Re: [PATCH v3 3/8] rsb: Linux driver framework for Reduced Serial Bus (RSB)
On Wed, Aug 19, 2015 at 12:20:04PM +0800, Chen-Yu Tsai wrote: Reduced Serial Bus (RSB) is an Allwinner proprietery interface used to communicate with PMICs and other peripheral ICs. drivers/rsb/Kconfig| 11 ++ drivers/rsb/Makefile | 4 + drivers/rsb/rsb-core.c | 511 + Based on the changelog and what you were saying in your other mail about this being very Allwinner specific I think the current trend would be to put this into drivers/soc rather than making a new top level directory in drivers. signature.asc Description: Digital signature
Re: [PATCHv2] arm64: dts: Add base stratix 10 dtsi
Hi,
+/ {
+ compatible = altr,socfpga-stratix10;
+ #address-cells = 1;
+ #size-cells = 1;
I would recommend that you make your root #address-cells and #size-cells equal
to 2, as that will simplify matters later if/when you need to add anything
beyond the first 4GB for some particular board.
If everything in the SoC falls within the first 4GB you can have a ranges
property on your /soc node and have only one cell below that.
[...]
+ intc: intc@8000 {
The unit-address doesn't match the first address in the reg entry.
+ compatible = arm,gic-400, arm,cortex-a15-gic;
+ #interrupt-cells = 3;
+ interrupt-controller;
+ reg = 0x0 0x9000 0x1000,
+ 0x0 0xa000 0x2000,
+ 0x0 0xc000 0x1000,
+ 0x0 0xd000 0x1000;
+ };
Shouldn't the virtual CPU interface also be 0x2000 long?
Mark.
--
To unsubscribe from this list: send the line unsubscribe devicetree 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: musb: omap2430: use *syscon* framework API to write to mailbox register
Hi, On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150805 07:10]: On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: We don't have syscon-otghs and to me it seems we need a PHY driver as I pointed out at: If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. OK great. https://lkml.org/lkml/2015/6/24/231 Maybe I should have explained this in the previous thread. The *otghs* register that we are trying to access here does _not_ belong to the PHY. It acts as mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why it's programmed in the TI glue layer (omap2430.c). Even when we were using the older API [omap_control_usb_set_mode()], we first call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the control module instead of PHY drivers directly calling omap_control_usb_set_mode(). Hmm looking at Table 18-204. CONTROL_USBOTGHS_CONTROL it seems to mention transceiver for quite a few bitfields :) Probably what that register does is control a PHY over ULPI. OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. So from Linux kernel point of view we're best off treating it as a PHY. It seems it should have a minimal PHY driver similar to what we have for dm816x control module in drivers/phy/phy-dm816x-usb.c. hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and should be programmed in omap2430.c. It's better to get the opinion of Felipe here. Felipe? For reference, here is the register bitfields pasted from 4460 TRM: Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 Physical Address 0x4A00 233C BIT NAMEDESCIPTION 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... 7 CHRGVBUS... OTG transceiver does (not) charge VBUS ... 6 IDPULLUP... OTG transceiver does (not) drive VBUS ... 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... 2 VBUSVALID ... VBUS is above the threshold ... 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us to completely get rid of the custom mailbox stuff for MUSB 2430 support? Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed for OMAP3 also. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe devicetree 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 0/8] arm64, numa: Add numa support for arm64 platforms.
Hi Maintainers, On Fri, Aug 14, 2015 at 10:14 PM, Ganapatrao Kulkarni gpkulka...@gmail.com wrote: On Fri, Aug 14, 2015 at 10:09 PM, Ganapatrao Kulkarni gkulka...@caviumnetworks.com wrote: v5: - created base verion of numa.c which creates dummy numa without using dt on single socket platforms. Then added patches for dt support. - Incorporated review comments from Hanjun Guo. v4: done changes as per Arnd review comments. v3: Added changes to support numa on arm64 based platforms. Tested these patches on cavium's multinode(2 node topology) platform. In this patchset, defined and implemented dt bindings for numa mapping for core and memory using device node property arm,associativity. v2: Defined and implemented numa map for memory, cores to node and proximity distance matrix of nodes. v1: Initial patchset to support numa on arm64 platforms. Note: 1. This patchset is tested for numa with dt on thunderx single socket and dual socket boards. 2. Numa DT booting needs the dt memory nodes, which are deleted in current efi-stub, hence to try numa with dt, you need to rebase with ard's patchset. http://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-uefi-early-fdt-handling Ganapatrao Kulkarni (4): arm64, numa: adding numa support for arm64 platforms. Documentation: arm64/arm: dt bindings for numa. arm64, numa: adding numa support for arm64 platforms. arm64, dt, thunderx: Add initial dts for Cavium Thunder SoC in 2 Node topology. Documentation/devicetree/bindings/arm/numa.txt | 212 +++ arch/arm64/Kconfig | 32 + arch/arm64/boot/dts/cavium/Makefile | 2 +- arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts | 78 +++ arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 790 arch/arm64/include/asm/mmzone.h | 32 + arch/arm64/include/asm/numa.h | 49 ++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/dt_numa.c | 316 ++ arch/arm64/kernel/setup.c | 9 + arch/arm64/kernel/smp.c | 3 + arch/arm64/mm/Makefile | 1 + arch/arm64/mm/init.c| 34 +- arch/arm64/mm/numa.c| 563 + 14 files changed, 2115 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/numa.txt create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi create mode 100644 arch/arm64/include/asm/mmzone.h create mode 100644 arch/arm64/include/asm/numa.h create mode 100644 arch/arm64/kernel/dt_numa.c create mode 100644 arch/arm64/mm/numa.c -- 1.8.1.4 sorry, minor correction, this patchset has 4 patches. PATCH v5 0/8 = PATCH v5 0/4 please review this patchset. thanks Ganapat -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C
On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote: Hi Vinod, On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote: On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote: This patch adds support for new feature CRC32C calculation in dmaengine framework. Looks okay can you please update Documentation also Thanks, I will update Documentation. Also add a wrapper for new API -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
From: VIET NGA DAO vn...@altera.com
Altera Quad SPI Controller is a soft IP which enables access to
Altera EPCS and EPCQ flash chips. This patch adds driver
for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v5:
- Remove Micron support
- Add multiple flashes probe failure handle
v4:
- Add more flash devices support ( EPCQL and Micron)
- Remove redundant messages
- Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
- Replace get_flash_name to altera_quadspi_scan
- Remove clk related parts
- Remove altera_quadspi_plat
- Change device tree reg name and remove opcode-id
v3:
- Change altera_epcq driver name to altera_quadspi for more generic name
- Implement flash name searching in altera_quadspi.c instead of spi-nor
- Edit the altra quadspi info table in spi-nor
- Remove wait_til_ready in all read,write, erase, lock, unlock functions
- Merge .h and .c into 1 file
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
drivers/mtd/spi-nor/Kconfig|8 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera-quadspi.c | 557
drivers/mtd/spi-nor/spi-nor.c | 18 +
5 files changed, 629 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/altera-quadspi.txt
create mode 100644 drivers/mtd/spi-nor/altera-quadspi.c
diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
new file mode 100644
index 000..e1bcf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
@@ -0,0 +1,45 @@
+* MTD Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be altr,quadspi-1.0
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ avl_csr: Should contain the register configuration base address
+ avl_mem: Should contain the data base address
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following fields:
+ - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024
+ 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw data;
+ reg = 0x0 0x100;
+ };
+ partition@100 {
+ /* 16 MB for jffs2 data. */
+ label = EPCQ Flash 0 JFFS 2;
+ reg = 0x100 0x100;
+ };
+ };
+ }; //end quadspi@0x180014a0 (quadspi_controller_0)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64a4f0e..5aa1197 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -28,4 +28,12 @@ config SPI_FSL_QUADSPI
This enables support for the Quad SPI controller in master mode.
We only connect the NOR to this controller now.
+config SPI_ALTERA_QUADSPI
+ tristate Altera Generic Quad SPI Controller
+ depends on OF
+ help
+ This enables access to Altera EPCQ/EPCS flash chips,
+ used for data storage. See the driver source for the current list,
+ or to add other chips.
+
endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 6a7ce14..4e700df 100644
---
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi Jingoo, On 08/20/2015 01:55 AM, Jingoo Han wrote: On 2015. 8. 20., at PM 3:23, Yakir Yang y...@rock-chips.com wrote: Hi Jingoo Archit, On 08/20/2015 12:54 AM, Jingoo Han wrote: On 2015. 8. 20., at PM 1:29, Archit Taneja arch...@codeaurora.org wrote: Hi, On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with analogix which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen cnm,n116bgeea2, both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some samsung* dts propery to analogix*. - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like link-rate = 0x0a lane-count = 4. - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave sclk_edp_24m to rockchip dp phy driver which name to 24m, and leave sclk_edp to analogix dp core driver which name to dp, and leave pclk_edp to rockchip dp platform driver which name to pclk. - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove rockchip,panel DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add analogix,need-force-hpd to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with sclk_edp sclk_edp_24m, leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol interlace colorimetry drm: bridge/analogix_dp: fix link_rate lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 +
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
On Thursday, August 20, 2015 at 08:55:05 AM, vn...@altera.com wrote:
From: VIET NGA DAO vn...@altera.com
Altera Quad SPI Controller is a soft IP which enables access to
Altera EPCS and EPCQ flash chips. This patch adds driver
for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v5:
- Remove Micron support
- Add multiple flashes probe failure handle
v4:
- Add more flash devices support ( EPCQL and Micron)
- Remove redundant messages
- Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
- Replace get_flash_name to altera_quadspi_scan
- Remove clk related parts
- Remove altera_quadspi_plat
- Change device tree reg name and remove opcode-id
v3:
- Change altera_epcq driver name to altera_quadspi for more generic name
- Implement flash name searching in altera_quadspi.c instead of spi-nor
- Edit the altra quadspi info table in spi-nor
- Remove wait_til_ready in all read,write, erase, lock, unlock functions
- Merge .h and .c into 1 file
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
drivers/mtd/spi-nor/Kconfig|8 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera-quadspi.c | 557
drivers/mtd/spi-nor/spi-nor.c |
18 +
5 files changed, 629 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mtd/altera-quadspi.txt create mode
100644 drivers/mtd/spi-nor/altera-quadspi.c
diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt new file mode
100644
index 000..e1bcf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
@@ -0,0 +1,45 @@
+* MTD Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be altr,quadspi-1.0
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ avl_csr: Should contain the register configuration base address
+ avl_mem: Should contain the data base address
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following
fields: + - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024
+ 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw data;
+ reg = 0x0 0x100;
+ };
+ partition@100 {
+ /* 16 MB for jffs2 data. */
+ label = EPCQ Flash 0 JFFS 2;
+ reg = 0x100 0x100;
+ };
IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).
+ };
+ }; //end quadspi@0x180014a0 (quadspi_controller_0)
Remove this incorrect comment.
[...]
+static struct flash_device flash_devices[] = {
+ FLASH_ID(epcs16, EPCS_OPCODE_ID, 0x14),
+ FLASH_ID(epcs64, EPCS_OPCODE_ID, 0x16),
+ FLASH_ID(epcs128, EPCS_OPCODE_ID, 0x18),
+
+ FLASH_ID(epcq16, NON_EPCS_OPCODE_ID, 0x15),
+ FLASH_ID(epcq32, NON_EPCS_OPCODE_ID, 0x16),
+ FLASH_ID(epcq64, NON_EPCS_OPCODE_ID, 0x17),
+ FLASH_ID(epcq128, NON_EPCS_OPCODE_ID, 0x18),
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
Sorry for missing to reply the last question
On Thu, Aug 20, 2015 at 4:13 PM, Nga Chi ngach...@gmail.com wrote:
On Thu, Aug 20, 2015 at 4:03 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, August 20, 2015 at 08:55:05 AM, vn...@altera.com wrote:
From: VIET NGA DAO vn...@altera.com
Altera Quad SPI Controller is a soft IP which enables access to
Altera EPCS and EPCQ flash chips. This patch adds driver
for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v5:
- Remove Micron support
- Add multiple flashes probe failure handle
v4:
- Add more flash devices support ( EPCQL and Micron)
- Remove redundant messages
- Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
- Replace get_flash_name to altera_quadspi_scan
- Remove clk related parts
- Remove altera_quadspi_plat
- Change device tree reg name and remove opcode-id
v3:
- Change altera_epcq driver name to altera_quadspi for more generic name
- Implement flash name searching in altera_quadspi.c instead of spi-nor
- Edit the altra quadspi info table in spi-nor
- Remove wait_til_ready in all read,write, erase, lock, unlock functions
- Merge .h and .c into 1 file
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
drivers/mtd/spi-nor/Kconfig|8 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera-quadspi.c | 557
drivers/mtd/spi-nor/spi-nor.c |
18 +
5 files changed, 629 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mtd/altera-quadspi.txt create mode
100644 drivers/mtd/spi-nor/altera-quadspi.c
diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt new file mode
100644
index 000..e1bcf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
@@ -0,0 +1,45 @@
+* MTD Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be altr,quadspi-1.0
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ avl_csr: Should contain the register configuration base address
+ avl_mem: Should contain the data base address
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following
fields: + - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512,
epcq1024
+ 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw
data;
+ reg = 0x0 0x100;
+ };
+ partition@100 {
+ /* 16 MB for jffs2 data. */
+ label = EPCQ Flash 0 JFFS 2;
+ reg = 0x100 0x100;
+ };
IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).
+ };
+ }; //end quadspi@0x180014a0 (quadspi_controller_0)
Remove this incorrect comment.
[...]
Do you mean the partition part below should not be in example?
partition@0 {
/* 16 MB for raw data. */
label = EPCQ Flash 0 raw data;
reg = 0x0 0x100;
Re: [PATCH v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function
Hi Jingoo,
On 08/20/2015 02:49 AM, Jingoo Han wrote:
On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote:
What is the reason to make this patch?
Please make commit message including the reason.
Okay, I think the below words would be okay :)
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge-enable(),
and place them into connector-detect().
Thanks,
- Yakir
Best regards,
Jingoo Han
Signed-off-by: Yakir Yang y...@rock-chips.com
---
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 75dd44a..052b9b3 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR(failed to disable the panel\n);
}
-ret = analogix_dp_detect_hpd(dp);
-if (ret) {
-/* Cable has been disconnected, we're done */
-return;
-}
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp-dev, unable to handle edid\n);
@@ -953,6 +947,12 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
static enum drm_connector_status analogix_dp_detect(
struct drm_connector *connector, bool force)
{
+struct analogix_dp_device *dp = connector_to_dp(connector);
+
+if (analogix_dp_detect_hpd(dp))
+/* Cable has been disconnected, we're done */
+return connector_status_disconnected;
+
return connector_status_connected;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
On Thursday, August 20, 2015 at 10:13:30 AM, Nga Chi wrote:
On Thu, Aug 20, 2015 at 4:03 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, August 20, 2015 at 08:55:05 AM, vn...@altera.com wrote:
From: VIET NGA DAO vn...@altera.com
Altera Quad SPI Controller is a soft IP which enables access to
Altera EPCS and EPCQ flash chips. This patch adds driver
for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v5:
- Remove Micron support
- Add multiple flashes probe failure handle
v4:
- Add more flash devices support ( EPCQL and Micron)
- Remove redundant messages
- Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
- Replace get_flash_name to altera_quadspi_scan
- Remove clk related parts
- Remove altera_quadspi_plat
- Change device tree reg name and remove opcode-id
v3:
- Change altera_epcq driver name to altera_quadspi for more generic name
- Implement flash name searching in altera_quadspi.c instead of spi-nor
- Edit the altra quadspi info table in spi-nor
- Remove wait_til_ready in all read,write, erase, lock, unlock functions
- Merge .h and .c into 1 file
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
drivers/mtd/spi-nor/Kconfig|8 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera-quadspi.c | 557
drivers/mtd/spi-nor/spi-nor.c
|
18 +
5 files changed, 629 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mtd/altera-quadspi.txt create mode
100644 drivers/mtd/spi-nor/altera-quadspi.c
diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt new file mode
100644
index 000..e1bcf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
@@ -0,0 +1,45 @@
+* MTD Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be altr,quadspi-1.0
+- reg: Address and length of the register set for the device. It
contains + the information of registers in the same order as described
by reg-names +- reg-names: Should contain the reg names
+ avl_csr: Should contain the register configuration base address
+ avl_mem: Should contain the data base address
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following
fields: + - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512,
epcq1024 + 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to
/mtd/partition.txt +
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw
data; + reg = 0x0
0x100; + };
+ partition@100 {
+ /* 16 MB for jffs2 data.
*/ + label = EPCQ Flash 0
JFFS 2; + reg = 0x100
0x100; + };
IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).
+ };
+ }; //end quadspi@0x180014a0 (quadspi_controller_0)
Remove this incorrect comment.
[...]
Do you mean the partition part below should not be in example?
partition@0 {
/* 16 MB for raw data. */
label = EPCQ Flash 0 raw
data; reg = 0x0
[PATCH v5 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
Also added a documentation file for this sensor's properties.
Signed-off-by: Adriana Reus adriana.r...@intel.com
---
No changes since v4 for the docs.
.../devicetree/bindings/iio/light/us5182d.txt | 23 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
b/Documentation/devicetree/bindings/iio/light/us5182d.txt
new file mode 100644
index 000..7785c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -0,0 +1,23 @@
+* UPISEMI us5182d I2C ALS and Proximity sensor
+
+Required properties:
+- compatible: must be upisemi,usd5182
+- reg: the I2C address of the device
+
+Optional properties:
+- upisemi,glass-coef: glass attenuation factor
+- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every
scale
+- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+
+Example:
+
+usd5182@39 {
+compatible = upisemi,usd5182;
+reg = 0x39;
+upisemi,glass-coef = 1000 ;
+upisemi,dark-ths = /bits/ 16 170 200 512 512 800 2000 4000
8000;
+upisemi,upper-dark-gain = /bits/ 8 0x00;
+upisemi,lower-dark-gain = /bits/ 8 0x16;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..5b40bab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -211,6 +211,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
truly Truly Semiconductors Limited
+upisemiuPI Semiconductor Corp.
usiUniversal Scientific Industrial Co., Ltd.
v3 V3 Semiconductor
variscite Variscite Ltd.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
On Thursday, August 20, 2015 at 11:18:14 AM, Viet Nga Dao wrote: Hi, [...] That is why we decided to upstream the driver. If the hardware fix, there might not need to have any changes in driver to support or if yes, it will be just minor. If the hardware can do proper READID opcode, this entire nonsense table will go away and a proper integration into the SPI NOR framework will take place. You might consider submitting this driver for staging, but I definitely am not a big fan of that. You might misunderstand the hardware problem i mention here. This soft IP controller is able to provide the ID for our Altera EPCS/EPCQ flash chips, which are non JEDEC chips. As from EPCQ device data sheet (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature /hb/cfg/cfg_cf52012.pdf), the device ID is 8 bit data. So what exactly is the output of READID instruction followed by 6 Byte read on an EPCQ chip? The remaining problem here is that this controller is able to support Micron chips but it currently has limitation in providing only 8 bit ID, which is not full JEDEC ID for Micron chips. OK Hence, we are asking hardware engineer to find out the solution so that the driver does not need to do any dirty hacking. And so, this table should still be here even hardware fix will take place or not. [...] Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe devicetree 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/14] Add Analogix Core Display Port Driver
On 2015. 8. 20., at PM 3:23, Yakir Yang y...@rock-chips.com wrote: Hi Jingoo Archit, On 08/20/2015 12:54 AM, Jingoo Han wrote: On 2015. 8. 20., at PM 1:29, Archit Taneja arch...@codeaurora.org wrote: Hi, On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with analogix which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen cnm,n116bgeea2, both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some samsung* dts propery to analogix*. - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like link-rate = 0x0a lane-count = 4. - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave sclk_edp_24m to rockchip dp phy driver which name to 24m, and leave sclk_edp to analogix dp core driver which name to dp, and leave pclk_edp to rockchip dp platform driver which name to pclk. - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove rockchip,panel DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add analogix,need-force-hpd to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with sclk_edp sclk_edp_24m, leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol interlace colorimetry drm: bridge/analogix_dp: fix link_rate lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 +
Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32
On Wed, Aug 19, 2015 at 01:56:39PM +0300, Yury wrote:
[...]
+++ b/include/linux/arm-smccc.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+#ifndef __LINUX_ARM_SMCCC_H
+#define __LINUX_ARM_SMCCC_H
+
+#include linux/types.h
+
+/*
+ * This file provideds defines common defines for ARM SMC Calling
typos here?
Thanks
+ * Convention as specified in
+ * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+ */
+
+#define SMCCC_SMC_32 (0 30)
0 30 is just 0, and so meaningless.
It's better to introduce SMCCC_IS_32() macro instead.
SMCCC_SMC_32 is used as an argument for SMCCC_CALL_VAL (example in
[PATCH v5 4/5] tee: add OP-TEE driver drivers/tee/optee/optee_smc.h).
Shifting 0 here is still 0 as you point out, but it connects it with the
other define SMCCC_SMC_64.
+#define SMCCC_SMC_64 (1 30)
+#define SMCCC_FAST_CALL(1 31)
+#define SMCCC_STD_CALL (0 31)
The same
+
+#define SMCCC_OWNER_MASK 0x3F
+#define SMCCC_OWNER_SHIFT 24
+
+#define SMCCC_FUNC_MASK0x
+
+#define SMCCC_IS_FAST_CALL(smc_val)((smc_val) SMCCC_FAST_CALL)
+#define SMCCC_IS_64(smc_val) ((smc_val) SMCCC_SMC_64)
+#define SMCCC_FUNC_NUM(smc_val)((smc_val) SMCCC_FUNC_MASK)
+#define SMCCC_OWNER_NUM(smc_val) \
+ (((smc_val) SMCCC_OWNER_SHIFT) SMCCC_OWNER_MASK)
+
+#define SMCCC_CALL_VAL(type, calling_convention, owner, func_num) \
+ ((type) | (calling_convention) | \
+ (((owner) SMCCC_OWNER_MASK) SMCCC_OWNER_SHIFT) | \
+ ((func_num) SMCCC_FUNC_MASK))
+
+#define SMCCC_OWNER_ARCH 0
+#define SMCCC_OWNER_CPU1
+#define SMCCC_OWNER_SIP2
+#define SMCCC_OWNER_OEM3
+#define SMCCC_OWNER_STANDARD 4
+#define SMCCC_OWNER_TRUSTED_APP48
+#define SMCCC_OWNER_TRUSTED_APP_END49
+#define SMCCC_OWNER_TRUSTED_OS 50
+#define SMCCC_OWNER_TRUSTED_OS_END 63
+
+struct smccc_param32 {
+ u32 a0;
+ u32 a1;
+ u32 a2;
+ u32 a3;
+ u32 a4;
+ u32 a5;
+ u32 a6;
+ u32 a7;
+};
+
+/**
+ * smccc_call32() - make ARCH32 SMC calls
+ * @param: values to pass in registers 0 to 7
+ *
+ * This function is used to make SMC calls following SMC Calling
Convention
+ * for ARCH32 calls. The content of the supplied param are copied to
+ * registers 0 to 7 prior to the SMC instruction. Values a0..a3
are updated
+ * with the content from register 0 to 3 on return from the SMC
+ * instruction.
+ */
+void smccc_call32(struct smccc_param32 *param);
+
+#endif /*__LINUX_ARM_SMCCC_H*/
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Thanks,
Jens
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function
On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote:
What is the reason to make this patch?
Please make commit message including the reason.
Best regards,
Jingoo Han
Signed-off-by: Yakir Yang y...@rock-chips.com
---
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 75dd44a..052b9b3 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR(failed to disable the panel\n);
}
-ret = analogix_dp_detect_hpd(dp);
-if (ret) {
-/* Cable has been disconnected, we're done */
-return;
-}
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp-dev, unable to handle edid\n);
@@ -953,6 +947,12 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
static enum drm_connector_status analogix_dp_detect(
struct drm_connector *connector, bool force)
{
+struct analogix_dp_device *dp = connector_to_dp(connector);
+
+if (analogix_dp_detect_hpd(dp))
+/* Cable has been disconnected, we're done */
+return connector_status_disconnected;
+
return connector_status_connected;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C
On Thu, Aug 20, 2015 at 12:38 PM, Vinod Koul vinod.k...@intel.com wrote: On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote: Hi Vinod, On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote: On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote: This patch adds support for new feature CRC32C calculation in dmaengine framework. Looks okay can you please update Documentation also Thanks, I will update Documentation. Also add a wrapper for new API Okay -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree 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/2] dma: Add Xilinx zynqmp dma engine driver support
On Thu, Aug 20, 2015 at 11:43 AM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
+ list_for_each_entry_safe(desc, next, chan-done_list, node) {
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ list_del(desc-node);
+
+ callback = desc-async_tx.callback;
+ callback_param = desc-async_tx.callback_param;
+ if (callback) {
+ if (in_interrupt())
+ spin_unlock_bh(chan-lock);
+ else
+ spin_unlock(chan-lock);
This looks bad!
Why would callback be called from different context. It should only be
invoked from your tasklet
During the terminate call, driver need to clean up the existing BDs so that time
this function will be called from the thread or process context in
addition to the
tasklet context.
DO you have any suggestion here ?
+static int zynqmp_dma_device_terminate_all(struct dma_chan *dchan)
+{
+ struct zynqmp_dma_chan *chan = to_chan(dchan);
+
+ spin_lock_bh(chan-lock);
+ zynqmp_dma_reset(chan);
+ spin_unlock_bh(chan-lock);
No descriptor cleanup
zynqmp_dma_reset will do the descriptor cleanup.
+static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
+{
+ if (!chan)
+ return;
+
+ devm_free_irq(chan-zdev-dev, chan-irq, chan);
+ tasklet_kill(chan-tasklet);
+ list_del(chan-common.device_node);
not deregistering with dmaengine?
This i am doing it in zynqmp_dma_remove function. Each channel will be
a standalone dma device for ZynqMP DMA case
+ zdev-chan = chan;
+ tasklet_init(chan-tasklet, zynqmp_dma_do_tasklet, (ulong)chan);
+ spin_lock_init(chan-lock);
+ INIT_LIST_HEAD(chan-active_list);
+ INIT_LIST_HEAD(chan-pending_list);
+ INIT_LIST_HEAD(chan-done_list);
+ INIT_LIST_HEAD(chan-free_list);
You can simmplify this by using vchan framework!
I got your point . but i have already said my reasons why i am
reluctant to use vchan framework in v3 review.
+MODULE_AUTHOR(Xilinx, Inc.);
+MODULE_DESCRIPTION(Xilinx ZynqMP DMA driver);
+MODULE_LICENSE(GPL);
No alias, how did it get loaded?
I will fix this. thanks.
Regards,
Punnaiah
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ARM: dts: sun8i: Add support for qt90h-v4 tablets
On Fri, Aug 14, 2015 at 04:44:37PM +0200, Hans de Goede wrote: The gt90h is a pcb found in generic 9 tablets with an A23 soc, 1G RAM and 8G nand, rtl8723as usb wifi, 1 micro usb port and 1 micro sd slot. This commit adds a dts for v4 of the gt90h pcb. Signed-off-by: Hans de Goede hdego...@redhat.com Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/6] ARM: dts: sun7i: Enable USB DRC on pcDuino 3
Hi, On 08/20/2015 08:45 AM, Maxime Ripard wrote: On Fri, Aug 14, 2015 at 04:44:35PM +0200, Hans de Goede wrote: From: Jelle van der Waa je...@vdwaa.nl Enable the otg/drc usb controller on the pcDuino 3. Note this board has the otg-vbus connected directly to the 5v-dcc of the board, so there is no vbus0 regulator, nor vbus0-det. Can it do OTG then? Yes. If VBUS is tied to the 5v, there's no way for the board to shut it down when acting as peripheral, right? Correct, the idea is to power it over otg when using it as a peripheral, or at least power it from a usb port of the machine for which it is a peripheral. Note that the original cubieboard (both A10 and A20 versions) have the same issue. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
Hi, On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: I'm not very helpful here, so hopefully Viet can be of more use: Yup :) On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: Also, I cannot find any documentation for this IP block even if I search through Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/litera ture/ hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. You can find the document at here (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_embedded_ip.pdf) Chapter 42.Page 407. For the soft IP issue, i've requested hardware engineer to come out the solution. So in the mean way, our driver will NOT support Micron flashes until hardware fix is completed. Hence, i just submitted version 5 for this driver with eliminating micron device support. Hope this version will get ACKed by you. Thanks, Viet Nga -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 2/9] Documentation: synopsys-dw-mshc: add bindings for idmac and edmac
synopsys-dw-mshc supports three types of transfer mode. We add
bindings and description for how to use them at runtime.
Signed-off-by: Shawn Lin shawn@rock-chips.com
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 346c609..8636f5a 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -75,6 +75,12 @@ Optional properties:
* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
specified we'll defer probe until we can find this regulator.
+* dmas: List of DMA specifiers with the controller specific format as described
+ in the generic DMA client binding. Refer to dma.txt for details.
+
+* dma-names: request names for generic DMA client binding. Must be rx-tx.
+ Refer to dma.txt for details.
+
Aliases:
- All the MSHC controller nodes should be represented in the aliases node using
@@ -95,6 +101,23 @@ board specific portions as listed below.
#size-cells = 0;
};
+[board specific internal DMA resources]
+
+ dwmmc0@1220 {
+ clock-frequency = 4;
+ clock-freq-min-max = 40 2;
+ num-slots = 1;
+ broken-cd;
+ fifo-depth = 0x80;
+ card-detect-delay = 200;
+ vmmc-supply = buck8;
+ bus-width = 8;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ };
+
+[board specific generic DMA request binding]
+
dwmmc0@1220 {
clock-frequency = 4;
clock-freq-min-max = 40 2;
@@ -106,4 +129,6 @@ board specific portions as listed below.
bus-width = 8;
cap-mmc-highspeed;
cap-sd-highspeed;
+ dmas = pdma 12;
+ dma-names = rx-tx;
};
--
2.3.7
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 4/9] arc: axs10x_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com Acked-by: Vineet Gupta vgu...@synopsys.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arc/configs/axs101_defconfig | 1 - arch/arc/configs/axs103_defconfig | 1 - arch/arc/configs/axs103_smp_defconfig | 1 - 3 files changed, 3 deletions(-) diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig index 562dac6..c92c0ef 100644 --- a/arch/arc/configs/axs101_defconfig +++ b/arch/arc/configs/axs101_defconfig @@ -89,7 +89,6 @@ CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig index 83a6d8d..cfac24e 100644 --- a/arch/arc/configs/axs103_defconfig +++ b/arch/arc/configs/axs103_defconfig @@ -95,7 +95,6 @@ CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig index f1e1c84..9922a11 100644 --- a/arch/arc/configs/axs103_smp_defconfig +++ b/arch/arc/configs/axs103_smp_defconfig @@ -96,7 +96,6 @@ CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 1/9] mmc: dw_mmc: Add external dma interface support
DesignWare MMC Controller can supports two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to support these platforms. I've tested it on RK31xx
platform with edmac mode and RK3288 platform with idmac mode.
Signed-off-by: Shawn Lin shawn@rock-chips.com
---
Changes in v6:
- add trans_mode condition for IDMAC initialization
suggested by Heiko
- re-test my patch on rk3188 platform and update commit msg
- update performance of pio vs edmac in cover letter
Changes in v5:
- add the title of cover letter
- fix typo of comment
- add macro for reading HCON register
- add Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com for
exynos_defconfig patch
- add Acked-by: Vineet Gupta vgu...@synopsys.com for axs10x_defconfig patch
- add Acked-by: Govindraj Raja govindraj.r...@imgtec.com and
Acked-by: Ralf Baechle r...@linux-mips.org for pistachio_defconfig patch
- add Acked-by: Joachim Eastwood manab...@gmail.com for lpc18xx_defconfig
patch
- add Acked-by: Wei Xu xuw...@hisilicon.com for hisi_defconfig patch
- rebase on https://github.com/jh80chung/dw-mmc.git tags/dw-mmc-for-ulf-v4.2
for merging easily
Changes in v4:
- remove host-trans_mode and use host-use_dma to indicate
transfer mode.
- remove all bt-bindings' changes since we don't need new properities.
- check transfer mode at runtime by reading HCON reg
- spilt defconfig changes for each sub-architecture
- fix the title of cover letter
- reuse some code for reducing code size
Changes in v3:
- choose transfer mode at runtime
- remove all CONFIG_MMC_DW_IDMAC config option
- add supports-idmac property for some platforms
Changes in v2:
- Fix typo of dev_info msg
- remove unused dmach from declaration of dw_mci_dma_slave
drivers/mmc/host/Kconfig| 11 +-
drivers/mmc/host/dw_mmc-pltfm.c | 2 +
drivers/mmc/host/dw_mmc.c | 264
drivers/mmc/host/dw_mmc.h | 5 +
include/linux/mmc/dw_mmc.h | 27 +++-
5 files changed, 242 insertions(+), 67 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 6a0f9c7..a86c0eb 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -607,15 +607,7 @@ config MMC_DW
help
This selects support for the Synopsys DesignWare Mobile Storage IP
block, this provides host support for SD and MMC interfaces, in both
- PIO and external DMA modes.
-
-config MMC_DW_IDMAC
- bool Internal DMAC interface
- depends on MMC_DW
- help
- This selects support for the internal DMAC block within the Synopsys
- Designware Mobile Storage IP block. This disables the external DMA
- interface.
+ PIO, internal DMA mode and external DMA modes.
config MMC_DW_PLTFM
tristate Synopsys Designware MCI Support as platform device
@@ -644,7 +636,6 @@ config MMC_DW_K3
tristate K3 specific extensions for Synopsys DW Memory Card Interface
depends on MMC_DW
select MMC_DW_PLTFM
- select MMC_DW_IDMAC
help
This selects support for Hisilicon K3 SoC specific extensions to the
Synopsys DesignWare Memory Card Interface driver. Select this option
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ec6dbcd..7e1d13b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,6 +59,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
host-pdata = pdev-dev.platform_data;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ /* Get registers' physical base address */
+ host-phy_regs = (void *)(regs-start);
host-regs = devm_ioremap_resource(pdev-dev, regs);
if (IS_ERR(host-regs))
return PTR_ERR(host-regs);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..f943619 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -56,7 +56,6 @@
#define DW_MCI_FREQ_MAX2 /* unit: HZ */
#define DW_MCI_FREQ_MIN40 /* unit: HZ */
-#ifdef CONFIG_MMC_DW_IDMAC
#define IDMAC_INT_CLR (SDMMC_IDMAC_INT_AI | SDMMC_IDMAC_INT_NI | \
SDMMC_IDMAC_INT_CES | SDMMC_IDMAC_INT_DU | \
SDMMC_IDMAC_INT_FBE | SDMMC_IDMAC_INT_RI | \
@@ -102,7 +101,6 @@ struct idmac_desc {
/* Each descriptor can transfer up to 4KB of data in chained mode */
#define DW_MCI_DESC_DATA_LENGTH0x1000
-#endif /* CONFIG_MMC_DW_IDMAC */
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -407,7 +405,6 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
return DMA_FROM_DEVICE;
}
-#ifdef CONFIG_MMC_DW_IDMAC
static void dw_mci_dma_cleanup(struct dw_mci *host)
{
struct
Re: [PATCH 3/6] ARM: dts: sun7i: Add regulator configuration to the pcduino3 dts file
On Fri, Aug 14, 2015 at 04:44:34PM +0200, Hans de Goede wrote: From: Jelle van der Waa je...@vdwaa.nl Add regulator configuration to the pcduino3 dts file. Signed-off-by: Jelle van der Waa je...@vdwaa.nl Signed-off-by: Hans de Goede hdego...@redhat.com Queued, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/6] ARM: dts: sun5i: Add simplefb node for tvencoder output
Hi, On Fri, Aug 14, 2015 at 04:44:32PM +0200, Hans de Goede wrote: Add a simplefb node for tvencoder / composite-video output, such as found on the Auxtek-T003 and the CHIP. Signed-off-by: Hans de Goede hdego...@redhat.com Queued, thanks! I guess the CHIP will have to have the same change for the A13 DTSI. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine
On Thu, Aug 20, 2015 at 12:23:50PM +0530, Rameshwar Sahu wrote:
Hi Vinod,
On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
+ /* Invalidate unused source address field */
+ for (; i 4; i++)
+ xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
+
+ /* Check whether requested buffer processed */
+ if (nbytes) {
+ chan_err(chan, Src count crossed maximum limit\n);
+ return -EINVAL;
no cleanup ?
Here not required, cleanup I am doing in parent function from where
this function is getting called in case of failure.
+struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
+ struct xgene_dma_chan *chan, struct scatterlist *src_sg,
+ size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
please fix style here
Could you explain me What kind of coding style you would like here ??
See CodingStyle Chapter 2
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Fixup mediatek spi driver
This series are based on 4.2-rc1 and provide four patches to fix mediatek spi driver. Change in v2: 1. The patch spi: mediatek: remove redundant clock in prepare_hardware/unprepare_hardware is applied, so remove it from series. 2. fix incorrect endian usage to support little-endian and big-endian system. 3. revise quirks style to bool. 4. use BIT() to instead of SPI_CMD_*_OFFSET. 5. revise coding style, such as time name, and variable type. -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Thu, Aug 20, 2015 at 11:41:33AM +0530, punnaiah choudary kalluri wrote: +- interrupts: Should contain DMA channel interrupt channel interrupt or interrupts, former says it is plural ZynqMP DMA has single interrupt for each channel So, that is the reason i have explicitly mentioned it as interrupt ( not interrupts). Please let me know if you still want it to be plural. The example had multiple values so plural sounds right -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver
On Tue, Jul 21, 2015 at 06:44:39PM +0530, Rameshwar Prasad Sahu wrote: This patch adds ACPI support for the APM X-Gene DMA engine driver. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On 08/20/2015 08:18 AM, Vinod Koul wrote: On Thu, Aug 20, 2015 at 11:41:33AM +0530, punnaiah choudary kalluri wrote: +- interrupts: Should contain DMA channel interrupt channel interrupt or interrupts, former says it is plural ZynqMP DMA has single interrupt for each channel So, that is the reason i have explicitly mentioned it as interrupt ( not interrupts). Please let me know if you still want it to be plural. The example had multiple values so plural sounds right I expect you are talking about this interrupts = 0 117 4; It is 3 cells format used on ARM based on gic spec which is on SPI interrupt 117 active high level-sensitive Documentation/devicetree/bindings/arm/gic.txt Thanks, Michal -- To unsubscribe from this list: send the line unsubscribe devicetree 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/2] dma: Add Xilinx zynqmp dma engine driver support
On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
+ list_for_each_entry_safe(desc, next, chan-done_list, node) {
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ list_del(desc-node);
+
+ callback = desc-async_tx.callback;
+ callback_param = desc-async_tx.callback_param;
+ if (callback) {
+ if (in_interrupt())
+ spin_unlock_bh(chan-lock);
+ else
+ spin_unlock(chan-lock);
This looks bad!
Why would callback be called from different context. It should only be
invoked from your tasklet
+static int zynqmp_dma_device_terminate_all(struct dma_chan *dchan)
+{
+ struct zynqmp_dma_chan *chan = to_chan(dchan);
+
+ spin_lock_bh(chan-lock);
+ zynqmp_dma_reset(chan);
+ spin_unlock_bh(chan-lock);
No descriptor cleanup
+static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
+{
+ if (!chan)
+ return;
+
+ devm_free_irq(chan-zdev-dev, chan-irq, chan);
+ tasklet_kill(chan-tasklet);
+ list_del(chan-common.device_node);
not deregistering with dmaengine?
+ zdev-chan = chan;
+ tasklet_init(chan-tasklet, zynqmp_dma_do_tasklet, (ulong)chan);
+ spin_lock_init(chan-lock);
+ INIT_LIST_HEAD(chan-active_list);
+ INIT_LIST_HEAD(chan-pending_list);
+ INIT_LIST_HEAD(chan-done_list);
+ INIT_LIST_HEAD(chan-free_list);
You can simmplify this by using vchan framework!
+MODULE_AUTHOR(Xilinx, Inc.);
+MODULE_DESCRIPTION(Xilinx ZynqMP DMA driver);
+MODULE_LICENSE(GPL);
No alias, how did it get loaded?
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Thu, Aug 20, 2015 at 11:22 AM, Vinod Koul vinod.k...@intel.com wrote: On Thu, Aug 06, 2015 at 08:49:32AM +0530, Punnaiah Choudary Kalluri wrote: Device-tree binding documentation for Xilinx zynqmp dma engine used in Zynq UltraScale+ MPSoC. Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v4: - None Changes in v3: - None Changes in v2: - None --- .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61 1 files changed, 61 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt new file mode 100644 index 000..e4f92b9 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt @@ -0,0 +1,61 @@ +Xilinx ZynqMP DMA engine, it does support memory to memory transfers, +memory to device and device to memory transfers. It also has flow +control and rate control support for slave/peripheral dma access. + +Required properties: +- compatible: Should be xlnx,zynqmp-dma-1.0 +- #dma-cells: Should be 1, a single cell holding a line request number +- reg: Memory map for module access +- interrupt-parent: Interrupt controller the interrupt is routed through +- interrupts: Should contain DMA channel interrupt channel interrupt or interrupts, former says it is plural ZynqMP DMA has single interrupt for each channel So, that is the reason i have explicitly mentioned it as interrupt ( not interrupts). Please let me know if you still want it to be plural. Regards, Punnaiah -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree 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 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect
On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote: Some edp screen with no hpd signal would need some delay time to ensure that screen would be ready for work, so we can expand the delay time in hpd detect function, it works prefectly on my rk3288 sdk board. Then, this delay has a dependency on the rk3288 sdk board. Also, if the delay time is expanded, the booting time of some Exybos boards will be increased unnecessarily. :-( So, please add new DT property such as 'hpd-delay' that can be added to board DT files. If there is not that DT property in DT files, the default value '10' will written to a variable such as 'unsigned int hpd_delay'. If there is the DT property in DT files, the delay value will written to the variable when parsing DT values and will be used in analogix_dp_detect_hpd(). What I want to say is that there should not be harmful effect on the existing Exynos boards, due to unrelated reasons. Best regards, Jingoo Han Signed-off-by: Yakir Yang y...@rock-chips.com --- Changes in v3: None Changes in v2: None drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix_dp_core.c index 99870f7..75dd44a 100644 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp) return 0; timeout_loop++; -usleep_range(10, 11); +usleep_range(100, 110); } /* -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
This patch adds support for R-Car generation 3 USB2 PHY driver.
This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
with the HSUSB (USB2.0 peripheral) device.
So, the purpose of this driver is:
1) initializes some registers of SoC specific to use the
{ehci,ohci}-platform driver.
2) detects id pin to select host or peripheral on the channel 0.
For now, this driver only supports 1) above.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
.../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 37 +++
drivers/phy/Kconfig| 6 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rcar-gen3-usb2.c | 262 +
4 files changed, 306 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
new file mode 100644
index 000..1e8437f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -0,0 +1,37 @@
+* Renesas R-Car generation 3 USB 2.0 PHY
+
+This file provides information on what the device node for the R-Car generation
+3 USB 2.0 PHY contains.
+
+Required properties:
+- compatible: renesas,usb2-phy-r8a7795 if the device is a part of R8A7795
SoC.
+- reg: offset and length of the USB2.0 host register block.
+- reg-names: must be usb2.
+- clocks: clock phandle and specifier pair.
+- clock-names: string, clock input name, must be usb2, and optional hsusb.
+- #phy-cells: see phy-bindings.txt in the same directory, must be 0.
+
+Optional proparies:
+To use a USB channel which EHCI/OHCI and HSUSB are combined, the device tree
+node should set HSUSB proparies to reg and reg-names proparies:
+- reg: offset and length of the HSUSB register block.
+- reg-names: must be hsusb.
+
+Example (R-Car H3):
+
+ usb-phy@ee080200 {
+ compatible = renesas,usb2-phy-r8a7795;
+ reg = 0 0xee080200 0 0x6ff, 0 0xe6590100 0 0x100;
+ reg-names = usb2, hsusb;
+ clocks = mstp7_clks R8A7795_CLK_EHCI0,
+mstp7_clks R8A7795_CLK_HSUSB;
+ clock-names = usb2, hsusb;
+ };
+
+ usb-phy@ee0a0200 {
+ compatible = renesas,usb2-phy-r8a7795;
+ reg = 0 0xee0a0200 0 0x6ff;
+ reg-names = usb2;
+ clocks = mstp7_clks R8A7795_CLK_EHCI0;
+ clock-names = usb2;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..ee300fa 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -118,6 +118,12 @@ config PHY_RCAR_GEN2
help
Support for USB PHY found on Renesas R-Car generation 2 SoCs.
+config PHY_RCAR_GEN3_USB2
+ tristate Renesas R-Car generation 3 USB 2.0 PHY driver
+ depends on GENERIC_PHY
+ help
+ Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
+
config OMAP_CONTROL_PHY
tristate OMAP CONTROL PHY Driver
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..97e83bc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_MIPHY28LP)+= phy-miphy28lp.o
obj-$(CONFIG_PHY_MIPHY365X)+= phy-miphy365x.o
obj-$(CONFIG_PHY_RCAR_GEN2)+= phy-rcar-gen2.o
+obj-$(CONFIG_PHY_RCAR_GEN3_USB2) += phy-rcar-gen3-usb2.o
obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
new file mode 100644
index 000..e319eaf
--- /dev/null
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -0,0 +1,262 @@
+/*
+ * Renesas R-Car Gen3 for USB2.0 PHY driver
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This is based on the phy-rcar-gen2 driver:
+ * Copyright (C) 2014 Renesas Solutions Corp.
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ *
+ * 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.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+#include asm/cmpxchg.h
+
+/*** USB2.0 Host registers (original offset is +0x200) ***/
+#define USB2_INT_ENABLE0x000
+#define USB2_USBCTR0x00c
+#define USB2_SPD_RSM_TIMSET0x10c
+#define USB2_OC_TIMSET 0x110
+
+/* INT_ENABLE */
+#define
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
On Thu, Aug 20, 2015 at 3:55 PM, Marek Vasut ma...@denx.de wrote: On Thursday, August 20, 2015 at 09:37:33 AM, Viet Nga Dao wrote: Hi, Hi, On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: I'm not very helpful here, so hopefully Viet can be of more use: Yup :) On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: Also, I cannot find any documentation for this IP block even if I search through Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/litera ture/ hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. You can find the document at here (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literatu re/ug/ug_embedded_ip.pdf) Chapter 42.Page 407. For the soft IP issue, i've requested hardware engineer to come out the solution. That's good :) So in the mean way, our driver will NOT support Micron flashes until hardware fix is completed. This doesn't answer my question, so let me reiterate. Is this controller only Soft IP (as in, FPGA core) or is this controller shipping in some chip as Hard IP (as in, piece of silicon) ? This is new soft IP. Hence, i just submitted version 5 for this driver with eliminating micron device support. Hope this version will get ACKed by you. We'll see. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 9/9] arm: zx_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/configs/zx_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/zx_defconfig b/arch/arm/configs/zx_defconfig index b200bb0..ab683fb 100644 --- a/arch/arm/configs/zx_defconfig +++ b/arch/arm/configs/zx_defconfig @@ -83,7 +83,6 @@ CONFIG_MMC=y CONFIG_MMC_UNSAFE_RESUME=y CONFIG_MMC_BLOCK_MINORS=16 CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_EXT2_FS=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 8/9] arm: multi_v7_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/configs/multi_v7_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 5fd8df6..a3734b5 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -520,7 +520,6 @@ CONFIG_MMC_ATMELMCI=y CONFIG_MMC_MVSDIO=y CONFIG_MMC_SDHI=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_PLTFM=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_ROCKCHIP=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 5/9] arm: exynos_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/configs/exynos_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..7e4af6e 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -161,7 +161,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_S3C=y CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 6/9] arm: hisi_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com Acked-by: Wei Xu xuw...@hisilicon.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/configs/hisi_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig index 5997dbc..b2e340b 100644 --- a/arch/arm/configs/hisi_defconfig +++ b/arch/arm/configs/hisi_defconfig @@ -69,7 +69,6 @@ CONFIG_NOP_USB_XCEIV=y CONFIG_MMC=y CONFIG_RTC_CLASS=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_PLTFM=y CONFIG_RTC_DRV_PL031=y CONFIG_DMADEVICES=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v6 7/9] arm: lpc18xx_defconfig: remove CONFIG_MMC_DW_IDMAC
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by: Shawn Lin shawn@rock-chips.com Acked-by: Joachim Eastwood manab...@gmail.com --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/configs/lpc18xx_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/lpc18xx_defconfig b/arch/arm/configs/lpc18xx_defconfig index 1c47f86..b7e8cda 100644 --- a/arch/arm/configs/lpc18xx_defconfig +++ b/arch/arm/configs/lpc18xx_defconfig @@ -119,7 +119,6 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_MMC=y CONFIG_MMC_DW=y -CONFIG_MMC_DW_IDMAC=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_PCA9532=y -- 2.3.7 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus
Hi, On 08/19/2015 05:17 PM, Maxime Ripard wrote: On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote: We've everything we need to support the gmac on Colombus, turn it on. Signed-off-by: Hans de Goede hdego...@redhat.com I recall that the phy was powered by one of the AXP221 regulators, does it require some additional stuff (like a recent u-boot), or does it just work and my memory is bad :) ? I think it just works, it MAY be connected to aldo1 but according to the git history for the u-boot defconfig that one is used for wifi not for the gmac, and we do not enable any other spare regulators in the u-boot config. I do not have any schematics, so no way to say for sure. I can confirm that the GMAC work fine with the latest u-boot master. Looking in the history we've always enabled ALDO1 on the Colombus in upstream u-boot, so this should all just work. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C
Hi Vinod, On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote: On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote: This patch adds support for new feature CRC32C calculation in dmaengine framework. Looks okay can you please update Documentation also Thanks, I will update Documentation. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe devicetree 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 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect
Hi Jingoo, On 08/20/2015 01:11 AM, Jingoo Han wrote: On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote: Some edp screen with no hpd signal would need some delay time to ensure that screen would be ready for work, so we can expand the delay time in hpd detect function, it works prefectly on my rk3288 sdk board. Then, this delay has a dependency on the rk3288 sdk board. Also, if the delay time is expanded, the booting time of some Exybos boards will be increased unnecessarily. :-( So, please add new DT property such as 'hpd-delay' that can be added to board DT files. If there is not that DT property in DT files, the default value '10' will written to a variable such as 'unsigned int hpd_delay'. If there is the DT property in DT files, the delay value will written to the variable when parsing DT values and will be used in analogix_dp_detect_hpd(). What I want to say is that there should not be harmful effect on the existing Exynos boards, due to unrelated reasons. Yeah, you are right, I made an mistake here. And I want to put this delay to need-force-hpd code, cause this property is for the no-hpd-signal eDP screen. But strangely, with my this series, I don't need the expand delay any more, I am not sure which change improved this, I guess those delay time should come from drm core ? Whatever seems we don't need this delay for now, and if I can find the exact reason and realize I still need this delay, I prefer to add those delay in need-force-hpd code. Thanks, - Yakir Best regards, Jingoo Han Signed-off-by: Yakir Yang y...@rock-chips.com --- Changes in v3: None Changes in v2: None drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix_dp_core.c index 99870f7..75dd44a 100644 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp) return 0; timeout_loop++; -usleep_range(10, 11); +usleep_range(100, 110); } /* -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor
Add support for UPISEMI us5182d als and proximity sensor. Supports raw readings. Data sheet for this device can be found here: http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf Signed-off-by: Adriana Reus adriana.r...@intel.com --- Changes since v4: * Added a comment explaining the opmode set/store behaviour. drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c | 507 3 files changed, 518 insertions(+) create mode 100644 drivers/iio/light/us5182d.c diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index 7ed859a..0442f01 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -287,6 +287,16 @@ config TSL4531 To compile this driver as a module, choose M here: the module will be called tsl4531. +config US5182D + tristate UPISEMI light and proximity sensor + depends on I2C + help +If you say yes here you get support for the UPISEMI US5182D +ambient light and proximity sensor. + +This driver can also be built as a module. If so, the module +will be called us5182d. + config VCNL4000 tristate VCNL4000 combined ALS and proximity sensor depends on I2C diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile index 91c74c0..528cc8f 100644 --- a/drivers/iio/light/Makefile +++ b/drivers/iio/light/Makefile @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310) += stk3310.o obj-$(CONFIG_TCS3414) += tcs3414.o obj-$(CONFIG_TCS3472) += tcs3472.o obj-$(CONFIG_TSL4531) += tsl4531.o +obj-$(CONFIG_US5182D) += us5182d.o obj-$(CONFIG_VCNL4000) += vcnl4000.o diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c new file mode 100644 index 000..7d356e6 --- /dev/null +++ b/drivers/iio/light/us5182d.c @@ -0,0 +1,507 @@ +/* + * Copyright (c) 2015 Intel Corporation + * + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor. + * + * 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 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. + * + * To do: Interrupt support. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/acpi.h +#include linux/delay.h +#include linux/i2c.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h +#include linux/mutex.h + +#define US5182D_REG_CFG0 0x00 +#define US5182D_CFG0_ONESHOT_ENBIT(6) +#define US5182D_CFG0_SHUTDOWN_EN BIT(7) +#define US5182D_CFG0_WORD_ENABLE BIT(0) + +#define US5182D_REG_CFG1 0x01 +#define US5182D_CFG1_ALS_RES16 BIT(4) +#define US5182D_CFG1_AGAIN_DEFAULT 0x00 + +#define US5182D_REG_CFG2 0x02 +#define US5182D_CFG2_PX_RES16 BIT(4) +#define US5182D_CFG2_PXGAIN_DEFAULTBIT(2) + +#define US5182D_REG_CFG3 0x03 +#define US5182D_CFG3_LED_CURRENT100(BIT(4) | BIT(5)) + +#define US5182D_REG_CFG4 0x10 + +/* + * Registers for tuning the auto dark current cancelling feature. + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling. + * when ALS DARK_TH -- ALS_Code = ALS - Upper(0x2A) * Dark + * when ALS DARK_TH -- ALS_Code = ALS - Lower(0x29) * Dark + */ +#define US5182D_REG_UDARK_TH 0x27 +#define US5182D_REG_DARK_AUTO_EN 0x2b +#define US5182D_REG_AUTO_LDARK_GAIN0x29 +#define US5182D_REG_AUTO_HDARK_GAIN0x2a + +#define US5182D_OPMODE_ALS 0x01 +#define US5182D_OPMODE_PX 0x02 +#define US5182D_OPMODE_SHIFT 4 + +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80 +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT0x16 +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT0x00 + +#define US5182D_REG_ADL0x0c +#define US5182D_REG_PDL0x0e + +#define US5182D_REG_MODE_STORE 0x21 +#define US5182D_STORE_MODE 0x01 + +#define US5182D_REG_CHIPID 0xb2 + +#define US5182D_OPMODE_MASKGENMASK(5, 4) +#define US5182D_AGAIN_MASK 0x07 +#define US5182D_RESET_CHIP 0x01 + +#define US5182D_CHIPID 0x26 +#define US5182D_DRV_NAME us5182d + +#define US5182D_GA_RESOLUTION 1000 + +#define
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
On Thursday, August 20, 2015 at 10:06:29 AM, Viet Nga Dao wrote: On Thu, Aug 20, 2015 at 3:55 PM, Marek Vasut ma...@denx.de wrote: On Thursday, August 20, 2015 at 09:37:33 AM, Viet Nga Dao wrote: Hi, Hi, On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: I'm not very helpful here, so hopefully Viet can be of more use: Yup :) On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: Also, I cannot find any documentation for this IP block even if I search through Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/lite ra ture/ hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. You can find the document at here (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/liter atu re/ug/ug_embedded_ip.pdf) Chapter 42.Page 407. For the soft IP issue, i've requested hardware engineer to come out the solution. That's good :) So in the mean way, our driver will NOT support Micron flashes until hardware fix is completed. This doesn't answer my question, so let me reiterate. Is this controller only Soft IP (as in, FPGA core) or is this controller shipping in some chip as Hard IP (as in, piece of silicon) ? This is new soft IP. I see, thanks ! Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor
Add support for UPISEMI us5182d als and proximity sensor. Supports raw readings. Data sheet for this device can be found here: http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf nitpicking below Signed-off-by: Adriana Reus adriana.r...@intel.com --- Changes since v4: * Added a comment explaining the opmode set/store behaviour. drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c | 507 3 files changed, 518 insertions(+) create mode 100644 drivers/iio/light/us5182d.c diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index 7ed859a..0442f01 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -287,6 +287,16 @@ config TSL4531 To compile this driver as a module, choose M here: the module will be called tsl4531. +config US5182D + tristate UPISEMI light and proximity sensor + depends on I2C + help + If you say yes here you get support for the UPISEMI US5182D + ambient light and proximity sensor. + + This driver can also be built as a module. If so, the module + will be called us5182d. + config VCNL4000 tristate VCNL4000 combined ALS and proximity sensor depends on I2C diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile index 91c74c0..528cc8f 100644 --- a/drivers/iio/light/Makefile +++ b/drivers/iio/light/Makefile @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310) += stk3310.o obj-$(CONFIG_TCS3414)+= tcs3414.o obj-$(CONFIG_TCS3472)+= tcs3472.o obj-$(CONFIG_TSL4531)+= tsl4531.o +obj-$(CONFIG_US5182D)+= us5182d.o obj-$(CONFIG_VCNL4000) += vcnl4000.o diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c new file mode 100644 index 000..7d356e6 --- /dev/null +++ b/drivers/iio/light/us5182d.c @@ -0,0 +1,507 @@ +/* + * Copyright (c) 2015 Intel Corporation + * + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor. + * + * 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 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. + * + * To do: Interrupt support. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/acpi.h +#include linux/delay.h +#include linux/i2c.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h +#include linux/mutex.h + +#define US5182D_REG_CFG0 0x00 +#define US5182D_CFG0_ONESHOT_EN BIT(6) +#define US5182D_CFG0_SHUTDOWN_EN BIT(7) +#define US5182D_CFG0_WORD_ENABLE BIT(0) + +#define US5182D_REG_CFG1 0x01 +#define US5182D_CFG1_ALS_RES16 BIT(4) +#define US5182D_CFG1_AGAIN_DEFAULT 0x00 + +#define US5182D_REG_CFG2 0x02 +#define US5182D_CFG2_PX_RES16BIT(4) +#define US5182D_CFG2_PXGAIN_DEFAULT BIT(2) + +#define US5182D_REG_CFG3 0x03 +#define US5182D_CFG3_LED_CURRENT100 (BIT(4) | BIT(5)) + +#define US5182D_REG_CFG4 0x10 + +/* + * Registers for tuning the auto dark current cancelling feature. + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling. + * when ALS DARK_TH -- ALS_Code = ALS - Upper(0x2A) * Dark + * when ALS DARK_TH -- ALS_Code = ALS - Lower(0x29) * Dark + */ +#define US5182D_REG_UDARK_TH 0x27 +#define US5182D_REG_DARK_AUTO_EN 0x2b +#define US5182D_REG_AUTO_LDARK_GAIN 0x29 +#define US5182D_REG_AUTO_HDARK_GAIN 0x2a + +#define US5182D_OPMODE_ALS 0x01 +#define US5182D_OPMODE_PX0x02 +#define US5182D_OPMODE_SHIFT 4 + +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80 +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT 0x16 +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT 0x00 + +#define US5182D_REG_ADL 0x0c +#define US5182D_REG_PDL 0x0e + +#define US5182D_REG_MODE_STORE 0x21 +#define US5182D_STORE_MODE 0x01 + +#define US5182D_REG_CHIPID 0xb2 + +#define US5182D_OPMODE_MASK GENMASK(5, 4) +#define US5182D_AGAIN_MASK 0x07 +#define US5182D_RESET_CHIP 0x01 + +#define US5182D_CHIPID
[PATCH] Altera Modular ADC driver device tree binding
From: Chee Nouk Phoon cnph...@altera.com
Altera Modular ADC is soft IP that wraps the hardened ADC block in a Max1
device. It can be configured to dual ADC mode that supports two channel
synchronous sampling or independent single ADCs. ADC sampled values will be
written into memory slots in sequence determined by a user configurable
sequencer block.
This patch adds device tree binding for Altera Modular ADC driver
Signed-off-by: Chee Nouk Phoon cnph...@altera.com
---
.../bindings/iio/adc/altr,modular-adc.txt | 63
1 files changed, 63 insertions(+), 0 deletions(-)
create mode 100755
Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
new file mode 100755
index 000..4106cb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
@@ -0,0 +1,63 @@
+Altera Modular (Dual) ADC
+
+This binding document describes both Altera Modular ADC and Altera Modular Dual
+ADC. Both options can be configured during generation time in Qsys. This driver
+only support standard sequencer with Avalon-MM sample storage with up to 64
+memory slots.
+
+Required properties:
+- compatible: must be one of the following strings
+ altr,modular-adc: single ADC configuration
+ altr,modular-dual-adc: dual ADC configuration
+
+- reg: Address and length of the register set for the device. It contains the
+ information of registers in the same order as described by reg-names
+
+- reg-names: Should contain the reg names
+ sequencer_csr: register region for adc sequencer block
+ sample_store_csr: register region for sample store block
+
+- interrupts: interrupt line for ADC
+
+- altr,adc-mode : ADC configuration
+ 1: single ADC mode
+ 2: dual ADC mode
+
+- altr,adc-slot-count : specify number of conversion slot in use
+
+- altr,adcADC index-slot-sequence-slot index: specify ADC channel
+ conversion sequence
+ ADC index: instantiated ADC number
+ slot index: slot index for ADC memory slot
+
+- altr,adc-number : specify ADC number when single ADC mode is selected
+ 1: 1st ADC
+ 2: 2nd ACD
+
+Example: single ADC
+modular_adc_0: adc@0x2200 {
+ compatible = altr,modular-adc;
+ reg = 0x2000 0x0008,
+0x2200 0x0200;
+ reg-names = sequencer_csr, sample_store_csr;
+ interrupt-parent = cpu;
+ interrupts = 8;
+ altr,adc-mode = 1;
+ altr,adc-slot-count = 2;
+ altr,adc1-slot-sequence-1 = 1;
+ altr,adc-number = 1;
+};
+
+Example: dual ADC
+modular_adc_1: adc@0x18002200 {
+ compatible = altr,modular-dual-adc;
+ reg = 0x18002000 0x0008,
+0x18002200 0x0200;
+ reg-names = sequencer_csr, sample_store_csr;
+ interrupt-parent = cpu;
+ interrupts = 8;
+ altr,adc-mode = 2;
+ altr,adc-slot-count = 1;
+ altr,adc1-slot-sequence-1 = 6;
+ altr,adc2-slot-sequence-1 = 6;
+};
\ No newline at end of file
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe devicetree 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/14] Add Analogix Core Display Port Driver
Hi Jingoo Archit, On 08/20/2015 12:54 AM, Jingoo Han wrote: On 2015. 8. 20., at PM 1:29, Archit Taneja arch...@codeaurora.org wrote: Hi, On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with analogix which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen cnm,n116bgeea2, both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some samsung* dts propery to analogix*. - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like link-rate = 0x0a lane-count = 4. - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave sclk_edp_24m to rockchip dp phy driver which name to 24m, and leave sclk_edp to analogix dp core driver which name to dp, and leave pclk_edp to rockchip dp platform driver which name to pclk. - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove rockchip,panel DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add analogix,need-force-hpd to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with sclk_edp sclk_edp_24m, leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol interlace colorimetry drm: bridge/analogix_dp: fix link_rate lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 + .../bindings/video/analogix_dp-rockchip.txt| 83 ++ .../devicetree/bindings/video/exynos_dp.txt| 51 +-
Re: [PATCH 4/6] ARM: dts: sun7i: Enable USB DRC on pcDuino 3
On Fri, Aug 14, 2015 at 04:44:35PM +0200, Hans de Goede wrote: From: Jelle van der Waa je...@vdwaa.nl Enable the otg/drc usb controller on the pcDuino 3. Note this board has the otg-vbus connected directly to the 5v-dcc of the board, so there is no vbus0 regulator, nor vbus0-det. Can it do OTG then? If VBUS is tied to the 5v, there's no way for the board to shut it down when acting as peripheral, right? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
Hi Vinod,
On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
+ nents = sg_nents(req-src);
+ sg_count = dma_map_sg(dev, req-src, nents, DMA_TO_DEVICE);
+ if (!sg_count) {
+ dev_err(dev, Failed to map src sg);
+ return -ENOMEM;
mapping error shouldn't be no mem error
Okay, I guess then -EIO will be fine here??
+ }
+
+ if (sg_count XGENE_DMA_MAX_FLYBY_SRC_CNT) {
+ dev_err(dev, Unsupported src sg len\n);
would be worth printing length
Okay,
+ goto err;
+ }
+
+ flags = DMA_CTRL_ACK;
why ACK?
My understanding about DMA_CTRL_ACK is dma engine driver can
re-use/free this descriptor once operation completed in cleanup path.
Am I correct ??
But yes, I need to look on this because recently you have added one
more descriptor flag.
+
+ tx = dchan-device-device_prep_dma_crc32c(dchan, req-src,
+req-nbytes,
+reqctx-seed,
+req-result,
+flags);
We should add helper for this
Okay
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 05/14] drm: bridge/analogix_dp: fix link_rate lane_count bug
On 2015. 8. 19., at PM 11:50, Yakir Yang y...@rock-chips.com wrote:
link_rate and lane_count already configed in analogix_dp_set_link_train(),
s/configed/configured
Also, the commit name such as fix ... bug is not good.
How about following?
drm: bridge/analogix_dp: remove duplicate configuration of link rate and link
count
Best regards,
Jingoo Han
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang y...@rock-chips.com
---
Changes in v3:
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
the DT property value directly, but we can take those as hardware limite.
For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
so DT property would like link-rate = 0x0a lane-count = 4.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 16
drivers/gpu/drm/bridge/analogix_dp_core.h | 9 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 480cc13..1778e0a 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+ * For DP rev.1.2, Maximum link rate of Main Link lanes
+ * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, data);
*bandwidth = data;
@@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, dp-link_train.lane_count);
if ((dp-link_train.link_rate != LINK_RATE_1_62GBPS)
-(dp-link_train.link_rate != LINK_RATE_2_70GBPS)) {
+(dp-link_train.link_rate != LINK_RATE_2_70GBPS)
+(dp-link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp-dev, Rx Max Link Rate is abnormal :%x !\n,
dp-link_train.link_rate);
dp-link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
-ret = analogix_dp_set_link_train(dp, dp-video_info-lane_count,
- dp-video_info-link_rate);
+ret = analogix_dp_set_link_train(dp, dp-video_info-max_lane_count,
+ dp-video_info-max_link_rate);
if (ret) {
dev_err(dp-dev, unable to do link train\n);
return;
@@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
-analogix_dp_set_lane_count(dp, dp-video_info-lane_count);
-analogix_dp_set_link_bandwidth(dp, dp-video_info-link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
@@ -1198,13 +1198,13 @@ static struct video_info
*analogix_dp_dt_parse_pdata(struct device *dev)
}
if (of_property_read_u32(dp_node, analogix,link-rate,
- dp_video_config-link_rate)) {
+ dp_video_config-max_link_rate)) {
dev_err(dev, failed to get link-rate\n);
return ERR_PTR(-EINVAL);
}
if (of_property_read_u32(dp_node, analogix,lane-count,
- dp_video_config-lane_count)) {
+ dp_video_config-max_lane_count)) {
dev_err(dev, failed to get lane-count\n);
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix_dp_core.h
index 2cefde9..941b34f 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP 5
enum link_rate_type {
-LINK_RATE_1_62GBPS = 0x06,
-LINK_RATE_2_70GBPS = 0x0a
+LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
};
enum link_lane_count_type {
@@ -128,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
-enum link_rate_type link_rate;
-enum link_lane_count_type lane_count;
+enum link_rate_type max_link_rate;
+enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
Hi Gab, Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni: Hi Lucas First of all many thanks for the quick reply, really appreciated -Original Message- From: Lucas Stach [mailto:l.st...@pengutronix.de] Sent: Wednesday, August 19, 2015 4:37 PM To: Gabriele Paoloni Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free- electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux- p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth) Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support Hi Gab, Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni: Hi Lucas I have rewritten the patch to take into account multiple controllers. As you can see now there is a static var in dw_pcie_host_init() that tracks the bus numbers used. This is wrong. The DT specifies the valid bus number range. You can not just assign the next free bus number to the root bus. I think this is what is being done in http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495 and currently designware assigns the root bus number in http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L730 You found the right spot. It works a bit different than I remember, but is less broken than your current code. :) It actually assigns the next instance a root bus number behind the current instances bus range. Please note the difference to your code which assigns the next free bus number, which may still lay within the current instances bus range. In general I agree with you but if you look at all the current drivers based on designware none of them define the bus-range dtb property. Therefore doing as you say would break the current driver when we have multiple controllers...am I right? The current _code_ works fine for multiple controllers. It's just that you must define the bus range property in the DTB if you want to enable multiple instances of one controller and support a kernel without PCI domains support. As all current implementations have only a single instance of the controller per SoC, or depend on PCI domain support, it's totally fine for them to not define the bus ranges property, as it's an optional property and it is well defined how things behave if it is absent. We absolutely need to keep that specified behavior. If that is the case in order to fix this in the way you say I would need to assign bus-range for all the PCIe drivers with multiple controllers: in this case I would split the default range evenly (that is, if we have two controllers I would define bus-range 0-127 and 128-255) If you think this solution is ok I can go for it. My only doubt was about touching other vendors DTBs You don't need to touch any of the current DTBs, as they are fine with the default bus range behavior. You need to keep the specified behavior of the bus range property with the new code. Regards, Lucas It is perfectly valid to have a bus range of 0x00-0x10 assigned to one instance and 0x50-0xff to the next instance. Additional with PCIe hotplug you may not use the full range of the bus numbers on one instance at the first scan, but only later populate more buses when more bridges are added to the tree. Drivers that do not specify the bus range in the DTB set pp- root_bus_nr = DW_ROOT_NR_UNDEFINED. Designware will check if the flag is set and will use the automatic bus range assignment. No, please lets get rid of this assignment altogether. The glue drivers have no business in assigning the bus range. Please remove the pp-root_bus_nr assignment from all the glue drivers. bus range is a generic DW PCIe property, so just parse the root bus number from the DT, it is handled the same way for all the DW based PCIe drivers. The bindings specifies that if the bus range property is missing the range is 0x00-0xff, so you can default to 0 as the root bus number in that case. Also I would think this conversion warrants a patch on its own and should not be mixed in the ARM64 support patch. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/2] Add support and documentation for UPISEMI us5182d als and proximity sensor
This series adds basic support for this als and proximity sensor and devicetree docs. Adriana Reus (2): iio: light: Add support for UPISEMI uS5182d als and proximity sensor devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor .../devicetree/bindings/iio/light/us5182d.txt | 23 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c| 507 + 5 files changed, 542 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt create mode 100644 drivers/iio/light/us5182d.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
On Tuesday, August 18, 2015 at 04:34:53 AM, vikas wrote:
Hi Marek,
Hi,
[...]
+#define CQSPI_POLL_IDLE_RETRY 3
+
+#define CQSPI_REG_SRAM_RESV_WORDS 2
+#define CQSPI_REG_SRAM_PARTITION_WR1
remove unused macros.
+#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
the macro is used only for write sram watermark, something like
...WR_THRESH_BYTES would be better. Infact instead of magic number like
50, it should be based on sram_depth similar to read watermark
configuration.
I suppose if the fifo falls below 1/8, that might be a sensible time to
trigger an underflow interrupt.
+
+/* Instruction type */
+#define CQSPI_INST_TYPE_SINGLE 0
+#define CQSPI_INST_TYPE_DUAL 1
+#define CQSPI_INST_TYPE_QUAD 2
+
+#define CQSPI_DUMMY_CLKS_MAX 31
+
+#define CQSPI_STIG_DATA_LEN_MAX8
+
+/* Register map */
+#define CQSPI_REG_CONFIG 0x00
+#define CQSPI_REG_CONFIG_ENABLE_MASK BIT(0)
+#define CQSPI_REG_CONFIG_DECODE_MASK BIT(9)
+#define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
+#define CQSPI_REG_CONFIG_DMA_MASK BIT(15)
+#define CQSPI_REG_CONFIG_BAUD_LSB 19
+#define CQSPI_REG_CONFIG_IDLE_LSB 31
To be consistent, it would be good to use BIT(nr) for all bit positions.
You don't use BIT() macro for bitfields and the above are bitfields.
Thus, this is not applicable.
+#define CQSPI_REG_CONFIG_CHIPSELECT_MASK 0xF
+#define CQSPI_REG_CONFIG_BAUD_MASK 0xF
[...]
+#define CQSPI_REG_CMDADDRESS 0x94
+#define CQSPI_REG_CMDREADDATALOWER 0xA0
+#define CQSPI_REG_CMDREADDATAUPPER 0xA4
+#define CQSPI_REG_CMDWRITEDATALOWER0xA8
+#define CQSPI_REG_CMDWRITEDATAUPPER0xAC
I am not sure if there is any recommended way but instread of register
macros with offset, isn't it better to use something like struct cdns_qspi
{
u32 config,
u32 rd_instn,
};
then configuring the pointer to this structure to the peripheral's (qspi
controller in this case) base address.
U-Boot is slowly abolishing this practice as it turned out to be a horrible
mistake, which is annoying to deal with . No, I will not do this.
It helps in debugging also as you can have all registers under one
structure, easy/clean access of register like cdsn_qspi_ptr-config
instead of adding offset for every access also clean picture of all
peripheral registers.
Once you have three similar controllers with only one register mapped
elsewhere, you'd need three such structures. This approach does look
nice at first, but certainly does not scale.
+
+/* Interrupt status bits */
+#define CQSPI_REG_IRQ_MODE_ERR BIT(0)
+#define CQSPI_REG_IRQ_UNDERFLOWBIT(1)
+#define CQSPI_REG_IRQ_IND_COMP BIT(2)
+#define CQSPI_REG_IRQ_IND_RD_REJECTBIT(3)
+#define CQSPI_REG_IRQ_WR_PROTECTED_ERR BIT(4)
+#define CQSPI_REG_IRQ_ILLEGAL_AHB_ERR BIT(5)
+#define CQSPI_REG_IRQ_WATERMARKBIT(6)
+#define CQSPI_REG_IRQ_IND_RD_OVERFLOW BIT(12)
[...]
+
+static unsigned int cqspi_check_timeout(const unsigned long timeout)
+{
+ return time_before(jiffies, timeout);
+}
try to replace using blocking jiffies check using kernel timeout function.
What function do you refer to ?
[...]
+static int cqspi_indirect_read_execute(struct spi_nor *nor,
+ u8 *rxbuf, const unsigned n_rx)
+{
+ struct cqspi_flash_pdata *f_pdata = nor-priv;
+ struct cqspi_st *cqspi = f_pdata-cqspi;
+ void __iomem *reg_base = cqspi-iobase;
+ void __iomem *ahb_base = cqspi-ahb_base;
+ unsigned int remaining = n_rx;
+ unsigned int reg = 0;
+ unsigned int bytes_to_read = 0;
+ unsigned int timeout;
+ int ret = 0;
+
+ writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
+
+ /* Clear all interrupts. */
+ writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS);
+
+ cqspi-irq_mask = CQSPI_IRQ_MASK_RD;
+ writel(cqspi-irq_mask, reg_base + CQSPI_REG_IRQMASK);
here interrupt mask is being configured for every read, better would be to
move it in init.
It certainly would not, it is configured differently for READ and WRITE.
+
+ reinit_completion(cqspi-transfer_complete);
+ writel(CQSPI_REG_INDIRECTRD_START_MASK,
+ reg_base + CQSPI_REG_INDIRECTRD);
+
+ while (remaining 0) {
+ ret =
[...]
+static void cqspi_controller_init(struct cqspi_st *cqspi)
[PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
Also added a documentation file for this sensor's properties.
Signed-off-by: Adriana Reus adriana.r...@intel.com
---
.../devicetree/bindings/iio/light/us5182d.txt | 23 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
b/Documentation/devicetree/bindings/iio/light/us5182d.txt
new file mode 100644
index 000..7785c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -0,0 +1,23 @@
+* UPISEMI us5182d I2C ALS and Proximity sensor
+
+Required properties:
+- compatible: must be upisemi,usd5182
+- reg: the I2C address of the device
+
+Optional properties:
+- upisemi,glass-coef: glass attenuation factor
+- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every
scale
+- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+
+Example:
+
+usd5182@39 {
+compatible = upisemi,usd5182;
+reg = 0x39;
+upisemi,glass-coef = 1000 ;
+upisemi,dark-ths = /bits/ 16 170 200 512 512 800 2000 4000
8000;
+upisemi,upper-dark-gain = /bits/ 8 0x00;
+upisemi,lower-dark-gain = /bits/ 8 0x16;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..5b40bab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -211,6 +211,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
truly Truly Semiconductors Limited
+upisemiuPI Semiconductor Corp.
usiUniversal Scientific Industrial Co., Ltd.
v3 V3 Semiconductor
variscite Variscite Ltd.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor
Add support for UPISEMI us5182d als and proximity sensor. Supports raw readings. Data sheet for this device can be found here: http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf Signed-off-by: Adriana Reus adriana.r...@intel.com --- Changes since v5: * fixed typos (thank you, Peter) drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c | 507 3 files changed, 518 insertions(+) create mode 100644 drivers/iio/light/us5182d.c diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index 7ed859a..0442f01 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -287,6 +287,16 @@ config TSL4531 To compile this driver as a module, choose M here: the module will be called tsl4531. +config US5182D + tristate UPISEMI light and proximity sensor + depends on I2C + help +If you say yes here you get support for the UPISEMI US5182D +ambient light and proximity sensor. + +This driver can also be built as a module. If so, the module +will be called us5182d. + config VCNL4000 tristate VCNL4000 combined ALS and proximity sensor depends on I2C diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile index 91c74c0..528cc8f 100644 --- a/drivers/iio/light/Makefile +++ b/drivers/iio/light/Makefile @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310) += stk3310.o obj-$(CONFIG_TCS3414) += tcs3414.o obj-$(CONFIG_TCS3472) += tcs3472.o obj-$(CONFIG_TSL4531) += tsl4531.o +obj-$(CONFIG_US5182D) += us5182d.o obj-$(CONFIG_VCNL4000) += vcnl4000.o diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c new file mode 100644 index 000..49dab3c --- /dev/null +++ b/drivers/iio/light/us5182d.c @@ -0,0 +1,507 @@ +/* + * Copyright (c) 2015 Intel Corporation + * + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor. + * + * 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 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. + * + * To do: Interrupt support. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/acpi.h +#include linux/delay.h +#include linux/i2c.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h +#include linux/mutex.h + +#define US5182D_REG_CFG0 0x00 +#define US5182D_CFG0_ONESHOT_ENBIT(6) +#define US5182D_CFG0_SHUTDOWN_EN BIT(7) +#define US5182D_CFG0_WORD_ENABLE BIT(0) + +#define US5182D_REG_CFG1 0x01 +#define US5182D_CFG1_ALS_RES16 BIT(4) +#define US5182D_CFG1_AGAIN_DEFAULT 0x00 + +#define US5182D_REG_CFG2 0x02 +#define US5182D_CFG2_PX_RES16 BIT(4) +#define US5182D_CFG2_PXGAIN_DEFAULTBIT(2) + +#define US5182D_REG_CFG3 0x03 +#define US5182D_CFG3_LED_CURRENT100(BIT(4) | BIT(5)) + +#define US5182D_REG_CFG4 0x10 + +/* + * Registers for tuning the auto dark current cancelling feature. + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling. + * when ALS DARK_TH -- ALS_Code = ALS - Upper(0x2A) * Dark + * when ALS DARK_TH -- ALS_Code = ALS - Lower(0x29) * Dark + */ +#define US5182D_REG_UDARK_TH 0x27 +#define US5182D_REG_DARK_AUTO_EN 0x2b +#define US5182D_REG_AUTO_LDARK_GAIN0x29 +#define US5182D_REG_AUTO_HDARK_GAIN0x2a + +#define US5182D_OPMODE_ALS 0x01 +#define US5182D_OPMODE_PX 0x02 +#define US5182D_OPMODE_SHIFT 4 + +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80 +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT0x16 +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT0x00 + +#define US5182D_REG_ADL0x0c +#define US5182D_REG_PDL0x0e + +#define US5182D_REG_MODE_STORE 0x21 +#define US5182D_STORE_MODE 0x01 + +#define US5182D_REG_CHIPID 0xb2 + +#define US5182D_OPMODE_MASKGENMASK(5, 4) +#define US5182D_AGAIN_MASK 0x07 +#define US5182D_RESET_CHIP 0x01 + +#define US5182D_CHIPID 0x26 +#define US5182D_DRV_NAME us5182d + +#define US5182D_GA_RESOLUTION 1000 + +#define US5182D_READ_BYTE
[PATCH v6 0/2] Add support and documentation for UPISEMI us5182d als and proximity sensor
This series adds basic support for this als and proximity sensor and devicetree docs. Adriana Reus (2): iio: light: Add support for UPISEMI uS5182d als and proximity sensor devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor .../devicetree/bindings/iio/light/us5182d.txt | 23 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c| 507 + 5 files changed, 542 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt create mode 100644 drivers/iio/light/us5182d.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HOW TO MAKE SAMPLES DIR IN THE MAINLINE KERNEL TO BE COMPILED AND CREATED .KO FILE IN THE SAME DIRECTORY
Hi Ravi, I'm wondering is your e-mail come from eDP thread ? cause I see lots of cc guys some as eDP emails :) And for your question, I am not sure I understand rightly. Do you mean that your .ko module not in the same directory with driver source code? If it's your question, I think you can fix it by add SUBDIRS flag in your driver makefile. I test it on kernel 3.14, but I think it would be okay on mainline kernel, it works good in my side, I see hello.ko in my hello/ [~/work/kernel-3.14/hello] 7392h41m $ ls hello.c hello.ko hello.mod.c hello.mod.o hello.o Makefile modules.order Module.symvers # My test makefile obj-m := hello.o KERNEL_DIR := ~/work/kernel-3.14 PWD := $(shell pwd) all: make -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules clean: rm *.o *.ko *.mod.c .PHONY:clean Wish can help, - Yakir On 08/20/2015 03:45 AM, ravi ranjan Mishra wrote: Hi , i did make in the kernel directory but sample directory is not able to compiled and generating .ko file in the same directory. can you please tell. Thanks, Ravi -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path
This patch fixes the an locking issue where client callback performs
further submission.
Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
---
drivers/dma/xgene-dma.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index d1c8809..0b82bc0 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct
xgene_dma_chan *chan)
struct xgene_dma_ring *ring = chan-rx_ring;
struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
struct xgene_dma_desc_hw *desc_hw;
+ struct list_head ld_completed;
u8 status;
+ INIT_LIST_HEAD(ld_completed);
+
+ spin_lock_bh(chan-lock);
+
/* Clean already completed and acked descriptors */
xgene_dma_clean_completed_descriptor(chan);
- /* Run the callback for each descriptor, in order */
+ /* Move all completed descriptors to ld completed queue, in order */
list_for_each_entry_safe(desc_sw, _desc_sw, chan-ld_running, node) {
/* Get subsequent hw descriptor from DMA rx ring */
desc_hw = ring-desc_hw[ring-head];
@@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct
xgene_dma_chan *chan)
/* Mark this hw descriptor as processed */
desc_hw-m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);
- xgene_dma_run_tx_complete_actions(chan, desc_sw);
-
- xgene_dma_clean_running_descriptor(chan, desc_sw);
-
/*
* Decrement the pending transaction count
* as we have processed one
*/
chan-pending--;
+
+ /*
+* Delete this node from ld running queue and append it to
+* ld completed queue for further processing
+*/
+ list_move_tail(desc_sw-node, ld_completed);
}
/*
@@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct
xgene_dma_chan *chan)
* ahead and free the descriptors below.
*/
xgene_chan_xfer_ld_pending(chan);
+
+ spin_unlock_bh(chan-lock);
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc_sw, _desc_sw, ld_completed, node) {
+ xgene_dma_run_tx_complete_actions(chan, desc_sw);
+ xgene_dma_clean_running_descriptor(chan, desc_sw);
+ }
}
static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
@@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct dma_chan
*dchan)
if (!chan-desc_pool)
return;
- spin_lock_bh(chan-lock);
-
/* Process all running descriptor */
xgene_dma_cleanup_descriptors(chan);
+ spin_lock_bh(chan-lock);
+
/* Clean all link descriptor queues */
xgene_dma_free_desc_list(chan, chan-ld_pending);
xgene_dma_free_desc_list(chan, chan-ld_running);
@@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
{
struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;
- spin_lock_bh(chan-lock);
-
/* Run all cleanup for descriptors which have been completed */
xgene_dma_cleanup_descriptors(chan);
/* Re-enable DMA channel IRQ */
enable_irq(chan-rx_irq);
-
- spin_unlock_bh(chan-lock);
}
static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support
Hi Lucas Again many thanks for explaining and for your time. I got your point now and I have dug a bit better in the PCI_DOMAINS code. However I have a question...see inline below -Original Message- From: Lucas Stach [mailto:l.st...@pengutronix.de] Sent: Thursday, August 20, 2015 9:27 AM To: Gabriele Paoloni Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free- electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux- p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth) Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support Hi Gab, Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni: Hi Lucas First of all many thanks for the quick reply, really appreciated -Original Message- From: Lucas Stach [mailto:l.st...@pengutronix.de] Sent: Wednesday, August 19, 2015 4:37 PM To: Gabriele Paoloni Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free- electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux- p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth) Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support Hi Gab, Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni: Hi Lucas I have rewritten the patch to take into account multiple controllers. As you can see now there is a static var in dw_pcie_host_init() that tracks the bus numbers used. This is wrong. The DT specifies the valid bus number range. You can not just assign the next free bus number to the root bus. I think this is what is being done in http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495 and currently designware assigns the root bus number in http://lxr.free-electrons.com/source/drivers/pci/host/pcie- designware.c#L730 You found the right spot. It works a bit different than I remember, but is less broken than your current code. :) It actually assigns the next instance a root bus number behind the current instances bus range. Please note the difference to your code which assigns the next free bus number, which may still lay within the current instances bus range. Mmmm here I have done a mistake: in the current designware the number of hw controllers is always 1 http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L510 So the loop in bios32.c does not work on multiple PCIe ports... However your comment about PCI_DOMAINS enlightened my mind and now I see that when CONFIG_PCI_DOMAINS is defined we have the domains numbers (tracked by __domain_nr). So (correct me if I am wrong) if we have 2 PCIe ports that do not specify the bus-range property, both root ports will enumerate starting from root_bus_nr = 0 and everything will still work ok. So if my assumption is correct, I do not see why the orginal patch from Wang Zhou is wrong. The only point can be that assigning pp-root_bus_nr = 0 is not required as pp memory is kzalloc'ed (an therefore init to zero). In general I agree with you but if you look at all the current drivers based on designware none of them define the bus-range dtb property. Therefore doing as you say would break the current driver when we have multiple controllers...am I right? The current _code_ works fine for multiple controllers. It's just that you must define the bus range property in the DTB if you want to enable multiple instances of one controller and support a kernel without PCI domains support. As all current implementations have only a single instance of the controller per SoC, or depend on PCI domain support, it's totally fine for them to not define the bus ranges property, as it's an optional property and it is well defined how things behave if it is absent. We absolutely need to keep that specified behavior. If that is the case in order to fix this in the way you say I would need to assign bus-range for all the PCIe drivers with multiple controllers: in this case I would split the default range evenly (that is, if we have two controllers I would define bus-range 0-127 and 128-255) If you think this solution is ok I can go for it. My only doubt was about touching other vendors DTBs You don't need to touch any of the current DTBs, as they are fine with the default bus range behavior. You need to keep the specified behavior of the bus range property with the new
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
Hello Marek,
On Thursday 20 August 2015 10:03:38, Marek Vasut wrote:
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = altr,quadspi-1.0;
+ reg = 0x180014a0 0x0020,
+ 0x1400 0x0400;
+ reg-names = avl_csr, avl_mem;
+ #address-cells = 1;
+ #size-cells = 0;
+ flash0: epcq256@0 {
+ compatible = altr,epcq256;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ /* 16 MB for raw data. */
+ label = EPCQ Flash 0 raw data;
+ reg = 0x0 0x100;
+ };
+ partition@100 {
+ /* 16 MB for jffs2 data. */
+ label = EPCQ Flash 0 JFFS 2;
+ reg = 0x100 0x100;
+ };
IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).
Do you mean specifying partitions in OF is deprecated in general? Is there any
link for that?
What would be an alternative to it?
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.st...@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax:+49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 1/5] arm/arm64: add smccc ARCH32
On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote: On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote: Adds helpers to do SMC based on ARM SMC Calling Convention. CONFIG_HAVE_SMCCC is enabled for architectures that may support the SMC instruction. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. [...] diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S new file mode 100644 index 000..3ce7fe8 --- /dev/null +++ b/arch/arm64/kernel/smccc-call.S @@ -0,0 +1,34 @@ +/* + * Copyright (c) 2015, Linaro Limited + * + * 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/linkage.h + +#define SMC_PARAM_W0_OFFS 0 +#define SMC_PARAM_W2_OFFS 8 +#define SMC_PARAM_W4_OFFS 16 +#define SMC_PARAM_W6_OFFS 24 + +/* void smccc_call32(struct smccc_param32 *param) */ +ENTRY(smccc_call32) + stp x28, x30, [sp, #-16]! Why are you saving lr? Agree, no point in saving lr, but I still need to decrease sp with 16 to maintain correct alignment. I'll do it with an str instruction instead. + mov x28, x0 + ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS] + ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS] + ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS] + ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS] + smc #0 + stp w0, w1, [x28, #SMC_PARAM_W0_OFFS] + stp w2, w3, [x28, #SMC_PARAM_W2_OFFS] + ldp x28, x30, [sp], #16 + ret +ENDPROC(smccc_call32) Could we deal with this like we do for PSCI instead? (see __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S and stick this in there too. I assume you're referring to when to use hvc and smc. I would rather consider smccc_call32() a primitive function that a driver may use if it's configured to do so, for instance via DT. When an hvc should be used instead of an smc up to the driver to decide based how it's configured. When merging psci-call.S and smccc-call.S into fw-call.S, what should I do about smccc.c? I need to export the smccc_call32 function somewhere as it could be used from a loadable module. -- Thanks, Jens -- To unsubscribe from this list: send the line unsubscribe devicetree 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/5] ARM: EXYNOS: DTS: add SROM device node for exynos4
Hi,
On Wednesday 27 May 2015 05:32 PM, Krzysztof Kozlowski wrote:
W dniu 29.04.2015 o 17:38, Pankaj Dubey pisze:
Add SROM device node for exynos4.
Subject prefix: ARM: dts:
Ok.
CC: Rob Herring robh...@kernel.org
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 77ea547..48490ea 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -76,6 +76,11 @@
reg = 0x1000 0x100;
};
+ sromc@1257 {
+ compatible = samsung,exynos-srom;
+ reg = 0x1257 0x100;
There are 5 registers, so size of 0x100 seems to be bigger than needed.
Maybe limit it to actual length?
Yes, we do not need size of 0x100. Will take care in next version.
Thanks,
Pankaj Dubey
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: EXYNOS: Remove SROM related register settings from mach-exynos
Hi Krzysztof, On Wednesday 27 May 2015 05:26 PM, Krzysztof Kozlowski wrote: W dniu 29.04.2015 o 17:38, Pankaj Dubey pisze: As now we have dedicated driver for SROM controller, it will take care of saving register banks during S2R so we can safely remove these settings from mach-exynos. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig | 2 + arch/arm/mach-exynos/exynos.c | 10 - arch/arm/mach-exynos/include/mach/map.h| 3 -- arch/arm/mach-exynos/suspend.c | 20 +- arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - arch/arm/plat-samsung/include/plat/regs-srom.h | 54 -- 6 files changed, 4 insertions(+), 86 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-srom.h diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 603820e..e842b23 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -25,6 +25,8 @@ menuconfig ARCH_EXYNOS select S5P_DEV_MFC select SRAM select MFD_SYSCON + select SOC_SAMSUNG + select EXYNOS_SROM What about the difference of execution time? The suspend/resume of device may not be called in the same time as previous syscore ops. Does this have any impact? I had tested it for S2R at that time on SMDK5250 board and it was fine. I do not noticed any issue in S2R, so I feel timing should not have any impact. Thanks, Pankaj Dubey Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe devicetree 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/5] drivers: soc: add support for exynos SROM driver
Hi Krzysztof,
Sorry for delay in reply, as I got busy in some other official
assignments and could not take this series further at that time.
On Wednesday 27 May 2015 05:22 PM, Krzysztof Kozlowski wrote:
W dniu 29.04.2015 o 17:38, Pankaj Dubey pisze:
This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.
Change-Id: Iaddaaebc1d7090c9889e948e68e886519562c43c
Please remove it.
Will do it.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/samsung/Kconfig | 14
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-srom.c | 142 ++
drivers/soc/samsung/exynos-srom.h | 51 ++
6 files changed, 210 insertions(+)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
create mode 100644 drivers/soc/samsung/exynos-srom.c
create mode 100644 drivers/soc/samsung/exynos-srom.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..c3abfbe 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
menu SOC (System On Chip) specific Drivers
source drivers/soc/qcom/Kconfig
+source drivers/soc/samsung/Kconfig
source drivers/soc/ti/Kconfig
source drivers/soc/versatile/Kconfig
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..620366f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_ARCH_QCOM) += qcom/
+obj-$(CONFIG_SOC_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..b6fa4e6
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,14 @@
+#
+# SAMSUNG SoC drivers
+#
+menu Samsung SOC driver support
+
+config SOC_SAMSUNG
+ bool
Any reason for not using menuconfig?
For one of my Exynos PMU patchset [1] this suggestion came from Russel
King, not to use user-visible sysmbol if not required.
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304451.html
+
+config EXYNOS_SROM
+ bool
+ depends on ARM ARCH_EXYNOS
+ select SOC_BUS
Why we need to select SOC_BUS?
We do not need it, will modify.
+
+endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..9c554d5
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
new file mode 100644
index 000..8aae762
--- /dev/null
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - SROM Controller support
+ * Author: Pankaj Dubey pankaj.du...@samsung.com
+ *
+ * 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.
+ */
+
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include exynos-srom.h
+
+static void __iomem *exynos_srom_base;
+
+static unsigned long exynos_srom_offsets[] = {
static const
+ /* SROM side */
+ S5P_SROM_BW,
+ S5P_SROM_BC0,
+ S5P_SROM_BC1,
+ S5P_SROM_BC2,
+ S5P_SROM_BC3,
+};
+
+/**
+ * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
+ * @offset: srom register offset from the controller base address.
+ * @value: the value to be register at offset.
Maybe:
@value: the value of register under the offset
OK.
+ */
+struct exynos_srom_reg_dump {
+ u32 offset;
+ u32 value;
+};
+
+static struct exynos_srom_reg_dump *exynos_srom_regs;
+
+static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
+ const unsigned long *rdump,
+ unsigned long nr_rdump)
+{
+ struct exynos_srom_reg_dump *rd;
+ unsigned int i;
+
+ rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
+ if (!rd)
+ return NULL;
+
+ for (i = 0; i nr_rdump; ++i)
+ rd[i].offset = rdump[i];
+
+ return rd;
+}
+
+static void exynos_srom_save(void __iomem *base,
+ struct exynos_srom_reg_dump *rd,
+ unsigned int num_regs)
+{
+ for (; num_regs 0; --num_regs, ++rd)
+ rd-value = readl(base + rd-offset);
+
+}
+
+static void exynos_srom_restore(void __iomem *base,
+ const struct
Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32
On 08/19/2015 06:50 PM, Will Deacon wrote: On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote: Adds helpers to do SMC based on ARM SMC Calling Convention. CONFIG_HAVE_SMCCC is enabled for architectures that may support the SMC instruction. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. [...] diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S new file mode 100644 index 000..3ce7fe8 --- /dev/null +++ b/arch/arm64/kernel/smccc-call.S @@ -0,0 +1,34 @@ +/* + * Copyright (c) 2015, Linaro Limited + * + * 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/linkage.h + +#define SMC_PARAM_W0_OFFS 0 +#define SMC_PARAM_W2_OFFS 8 +#define SMC_PARAM_W4_OFFS 16 +#define SMC_PARAM_W6_OFFS 24 + +/* void smccc_call32(struct smccc_param32 *param) */ +ENTRY(smccc_call32) + stp x28, x30, [sp, #-16]! Why are you saving lr? + mov x28, x0 + ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS] + ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS] + ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS] + ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS] + smc #0 + stp w0, w1, [x28, #SMC_PARAM_W0_OFFS] + stp w2, w3, [x28, #SMC_PARAM_W2_OFFS] + ldp x28, x30, [sp], #16 + ret +ENDPROC(smccc_call32) Could we deal with this like we do for PSCI instead? (see __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S and stick this in there too. I think that make sense to make smc, hvc calling more generic. Remove psci name from __invoke_psci_fn_smc and just use it in other drivers. Thanks, Michal -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/4] i2c: tegra: implement slave mode
On 24.07.2015 13:52, Wolfram Sang wrote:
At the begin of my work on this patchset I even denied clock disable call if
slave is registered (to minimize code that can affect transfer).
I hacked something like this, but it seems it was not enough.
If only slave mode is used, then this logic is not needed.
This is not sufficent. We shouldn't break being a master only because we
also listen to a slave address (as long as the HW supports that of
course).
tegra_i2c_init is called on probe and resume. Also it is called in case of
xfer fail. If xfer is ok, then I think slave addr must be kept unchanged.
This is fragile. Try scanning the bus with i2cdetect and slave setup
will be gone.
As far as I understand it is a loopback mode. Probably it will not work
(Stephen Warren already mentioned this).
Just to make clear: I am not saying we should support talking to our own
slave address. But it should still be possible to communicate with other
remote devices on the bus.
Sorry for the long delay. I tried to analyze the issue. Attached patch
works on AC100 (Misha Komarovsky helped me with testing).
Wolfram could you please try the patch with your environment?
Thanks.
From 0927b4007786b19e51415c4900863dd4e74fa034 Mon Sep 17 00:00:00 2001
From: Andrey Danin danind...@mail.ru
Date: Thu, 20 Aug 2015 00:41:39 +0300
Subject: [PATCH] i2c: tegra: don't reset I2C slave address on init
Init function is called multuple times. If I2C controller works
in slave mode, then driver must keep slave registers otherwise
slave configuration will be reseted.
Signed-off-by: Andrey Danin danind...@mail.ru
---
drivers/i2c/busses/i2c-tegra.c | 42 +--
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 6467ce0..50250a1 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -402,6 +402,22 @@ static void tegra_dvc_init(struct tegra_i2c_dev *i2c_dev)
dvc_writel(i2c_dev, val, DVC_CTRL_REG1);
}
+static int tegra_i2c_init_slave(struct tegra_i2c_dev *i2c_dev, u32 addr, u32
flags)
+{
+ int addr2 = 0;
+
+ i2c_writel(i2c_dev, I2C_SL_CNFG_NEWSL, I2C_SL_CNFG);
+ i2c_writel(i2c_dev, I2C_SL_DELAY_COUNT_DEFAULT, I2C_SL_DELAY_COUNT);
+
+ if (flags I2C_CLIENT_TEN)
+ addr2 = (addr 7) | I2C_SL_ADDR2_TEN_BIT_MODE;
+
+ i2c_writel(i2c_dev, addr, I2C_SL_ADDR1);
+ i2c_writel(i2c_dev, addr2, I2C_SL_ADDR2);
+
+ return 0;
+}
+
static inline int tegra_i2c_clock_enable(struct tegra_i2c_dev *i2c_dev)
{
int ret;
@@ -461,12 +477,16 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
i2c_writel(i2c_dev, clk_divisor, I2C_CLK_DIVISOR);
if (!i2c_dev-is_dvc) {
- u32 sl_cfg = i2c_readl(i2c_dev, I2C_SL_CNFG);
- sl_cfg |= I2C_SL_CNFG_NACK | I2C_SL_CNFG_NEWSL;
- i2c_writel(i2c_dev, sl_cfg, I2C_SL_CNFG);
- i2c_writel(i2c_dev, 0xfc, I2C_SL_ADDR1);
- i2c_writel(i2c_dev, 0x00, I2C_SL_ADDR2);
-
+ if (i2c_dev-slave) {
+ tegra_i2c_init_slave(i2c_dev, i2c_dev-slave-addr,
+ i2c_dev-slave-flags);
+ } else {
+ u32 sl_cfg = i2c_readl(i2c_dev, I2C_SL_CNFG);
+ sl_cfg |= I2C_SL_CNFG_NACK | I2C_SL_CNFG_NEWSL;
+ i2c_writel(i2c_dev, sl_cfg, I2C_SL_CNFG);
+ i2c_writel(i2c_dev, 0xfc, I2C_SL_ADDR1);
+ i2c_writel(i2c_dev, 0x00, I2C_SL_ADDR2);
+ }
}
val = 7 I2C_FIFO_CONTROL_TX_TRIG_SHIFT |
@@ -767,7 +787,6 @@ static u32 tegra_i2c_func(struct i2c_adapter *adap)
static int tegra_reg_slave(struct i2c_client *slave)
{
struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(slave-adapter);
- int addr2 = 0;
if (i2c_dev-slave)
return -EBUSY;
@@ -776,14 +795,7 @@ static int tegra_reg_slave(struct i2c_client *slave)
tegra_i2c_clock_enable(i2c_dev);
- i2c_writel(i2c_dev, I2C_SL_CNFG_NEWSL, I2C_SL_CNFG);
- i2c_writel(i2c_dev, I2C_SL_DELAY_COUNT_DEFAULT, I2C_SL_DELAY_COUNT);
-
- if (slave-flags I2C_CLIENT_TEN)
- addr2 = (slave-addr 7) | I2C_SL_ADDR2_TEN_BIT_MODE;
-
- i2c_writel(i2c_dev, slave-addr, I2C_SL_ADDR1);
- i2c_writel(i2c_dev, addr2, I2C_SL_ADDR2);
+ tegra_i2c_init_slave(i2c_dev, slave-addr, slave-flags);
return 0;
}
--
1.7.1
Re: [PATCH 5/5] Documentation: dt-bindings: add exynos-srom binding information
Hi Krzysztof, On Wednesday 27 May 2015 04:51 PM, Krzysztof Kozlowski wrote: 2015-04-29 17:38 GMT+09:00 Pankaj Dubey pankaj.du...@samsung.com: This patch adds exynos-srom binding information for SROM Controller driver on Exynos SoCs. CC: Rob Herring robh...@kernel.org CC: Mark Rutland mark.rutl...@arm.com CC: Ian Campbell ijc+devicet...@hellion.org.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- .../devicetree/bindings/arm/samsung/exynos-srom.txt | 12 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt new file mode 100644 index 000..482d1cd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt @@ -0,0 +1,12 @@ +SAMSUNG Exynos SoCs SROM Controller driver. + +Required properties: +- compatible : Should at least contain samsung,exynos-srom. At least - do you already expect other compatibles? Nope, as of now I do not expect any other compatible, so I will change this to Should contain samsung,exynos-srom. Thanks, Pankaj Dubey Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: ti_am335x_tsc: Add open delay parameter
On 08/19/2015 11:38 PM, Michael Welling wrote:
On Wed, Aug 12, 2015 at 01:44:22PM -0500, Michael Welling wrote:
On Wed, Aug 12, 2015 at 11:56:36AM +0530, Vignesh R wrote:
Hi Michael,
+ Dmitry
On 08/12/2015 12:15 AM, Michael Welling wrote:
Adds a device tree parameter to set the open delay on the touchscreen
conversion steps. Increasing this parameter helps the touch accuracy on
some screens.
Signed-off-by: Michael Welling mwell...@ieee.org
---
.../bindings/input/touchscreen/ti-tsc-adc.txt | 5 +
drivers/input/touchscreen/ti_am335x_tsc.c | 18
++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index b1163bf..cb11fda 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -41,6 +41,11 @@ Optional properties:
charge step, so this does in fact function as a
hardware knob for adjusting the amount of settling
time.
+ ti,open-delay: Open delay applied to all touchscreen conversion steps.
+ The value corresponds to the number of ADC clock
+ cycles to wait after applying the step configuration
+ registers and before sending the start of ADC
+ conversion. Maximum value is 0x3.
Since open-delay is per step, is it not better to allow specifying
open-delay per step like ti,chan-step-opendelay of adc? This will help
control open-delay for all the four wires.
Do you see any reason why you would want a different delay for each step of
the conversion on the same touchscreen?
Sorry for the delay,
I haven't seen different delays being used for different channels on
4-wire TSC ( not sure of 5-wire or 8 wire designs). Since this is DT
change, I just wanted to make sure more flexibility is provided.
The user would need to know the number of steps what each of the steps do.
What I was thinking was making open-delay configurable per channel (one
entry for X+, X-, Y+, Y-).
For example, for a 4-wire TSC:
ti,chan-open-delay = 0x30 0x100 0x20 0x10; /* for X+, X-, Y+, Y- */
- child adc
ti,chan-step-opendelay: List of open delays for each channel of
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 191a1b8..37a9729 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -54,6 +54,7 @@ struct titsc {
u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
u32 charge_delay;
+ u32 open_delay;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -148,7 +149,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + tsc_steps;
for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), ts_dev-open_delay);
}
config = 0;
@@ -172,7 +173,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + ts_dev-coordinate_readouts;
for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), ts_dev-open_delay);
}
/* Make CHARGECONFIG same as IDLECONFIG */
@@ -188,13 +189,13 @@ static void titsc_step_config(struct titsc *ts_dev)
STEPCONFIG_INP(ts_dev-inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ ts_dev-open_delay);
end_step++;
config |= STEPCONFIG_INP(ts_dev-inp_yn);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ ts_dev-open_delay);
/* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
stepenable = 1;
@@ -392,6 +393,15 @@ static int titsc_parse_dt(struct platform_device
*pdev,
dev_warn(pdev-dev, ti,charge-delay not specified\n);
}
+ err = of_property_read_u32(node, ti,open-delay,
+ ts_dev-open_delay);
+ /*
+ * If ti,open-delay value is not specified, then use
+ * STEPCONFIG_OPENDLY as the default value.
+ */
+ if (err 0)
+ ts_dev-open_delay = STEPCONFIG_OPENDLY;
+
return of_property_read_u32_array(node, ti,wire-config,
Re: [PATCH v2] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes
On Wed, Aug 19, 2015 at 02:49:26PM +0900, Masahiro Yamada wrote: This SoC is integrated with 4 Cortex-A9 cores. The GIC bindings document says that the bits[15:8] of the 3rd cell of the interrupts property represents PPI interrupt CPU mask. Because the timer interrupts are wired to all of the 4 cores, bits[15:8] should be set to 0xf. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Changes in v2: - Fix git-description Thanks, applied. -Olof -- To unsubscribe from this list: send the line unsubscribe devicetree 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/5] drivers: soc: add support for exynos SROM driver
On 20.08.2015 20:34, Pankaj Dubey wrote: Hi Krzysztof, Sorry for delay in reply, as I got busy in some other official assignments and could not take this series further at that time. On Wednesday 27 May 2015 05:22 PM, Krzysztof Kozlowski wrote: W dniu 29.04.2015 o 17:38, Pankaj Dubey pisze: This patch adds Exynos SROM controller driver which will handle save restore of SROM registers during S2R. Change-Id: Iaddaaebc1d7090c9889e948e68e886519562c43c Please remove it. Will do it. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/samsung/Kconfig | 14 drivers/soc/samsung/Makefile | 1 + drivers/soc/samsung/exynos-srom.c | 142 ++ drivers/soc/samsung/exynos-srom.h | 51 ++ 6 files changed, 210 insertions(+) create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-srom.c create mode 100644 drivers/soc/samsung/exynos-srom.h diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 76d6bd4..c3abfbe 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -1,6 +1,7 @@ menu SOC (System On Chip) specific Drivers source drivers/soc/qcom/Kconfig +source drivers/soc/samsung/Kconfig source drivers/soc/ti/Kconfig source drivers/soc/versatile/Kconfig diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..620366f 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_ARCH_QCOM)+= qcom/ +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/ obj-$(CONFIG_ARCH_TEGRA)+= tegra/ obj-$(CONFIG_SOC_TI)+= ti/ obj-$(CONFIG_PLAT_VERSATILE)+= versatile/ diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index 000..b6fa4e6 --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,14 @@ +# +# SAMSUNG SoC drivers +# +menu Samsung SOC driver support + +config SOC_SAMSUNG +bool Any reason for not using menuconfig? For one of my Exynos PMU patchset [1] this suggestion came from Russel King, not to use user-visible sysmbol if not required. [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304451.html Okay, thanks. I'm fine with that. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t104xd4rdb: add DS26522 nodes to device tree
DS26522 is used for tdm, configured by SPI bus.
Add nodes under spi node to t104xd4rdb.dtsi.
Signed-off-by: Zhao Qiang qiang.z...@freescale.com
---
Documentation/devicetree/bindings/net/maxim,ds26522.txt | 13 +
arch/powerpc/boot/dts/t104xd4rdb.dtsi | 10 ++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/maxim,ds26522.txt
diff --git a/Documentation/devicetree/bindings/net/maxim,ds26522.txt
b/Documentation/devicetree/bindings/net/maxim,ds26522.txt
new file mode 100644
index 000..ee8bb72
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxim,ds26522.txt
@@ -0,0 +1,13 @@
+* Maxim (Dallas) DS26522 Dual T1/E1/J1 Transceiver
+
+Required properties:
+- compatible: Should contain maxim,ds26522.
+- reg: SPI CS.
+- spi-max-frequency: SPI clock.
+
+Example:
+ slic@1 {
+ compatible = maxim,ds26522;
+ reg = 1;
+ spi-max-frequency = 200; /* input clock */
+ };
diff --git a/arch/powerpc/boot/dts/t104xd4rdb.dtsi
b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
index 491367b..3f6d7c6 100644
--- a/arch/powerpc/boot/dts/t104xd4rdb.dtsi
+++ b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
@@ -109,6 +109,16 @@
/* input clock */
spi-max-frequency = 1000;
};
+ slic@1 {
+ compatible = maxim,ds26522;
+ reg = 1;
+ spi-max-frequency = 200; /* input clock */
+ };
+ slic@2 {
+ compatible = maxim,ds26522;
+ reg = 2;
+ spi-max-frequency = 200; /* input clock */
+ };
};
i2c@118000 {
hwmon@4c {
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add VIN and ADV7180 device tree support for R8A7794/SILK board
On Thu, Aug 20, 2015 at 11:19:11PM +0300, Sergei Shtylyov wrote: On 08/20/2015 10:04 PM, Sergei Shtylyov wrote: Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20150819-v4.2-rc7' tag. Here we add the VIN and ADV7180 video decoder device tree support on the R8A7794/SILK board. The patchset requires previously posted SILK SDHI1 support patch in order to apply and R8A7794/SILK I2C1 support in order to apply and build. [1/2] ARM: shmobile: r8a7794: add VIN DT support [2/2] ARM: shmobile: silk: add VIN0/ADV7180 DT support Thanks, I have queued these up for v4.4. Perhaps a bit too early: the PFC VIN patch hasn't been merged yet. Sorry for not specifying the PFC dependency... OTOH, the frames get captured somehow even without the PFC patch, so might as well leave these patches applied. Your choice... Thanks. I will defer these patches for now. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver
On Fri, Aug 21, 2015 at 4:37 AM, Brian Norris computersforpe...@gmail.com wrote: On Thu, Aug 20, 2015 at 05:18:14PM +0800, Viet Nga Dao wrote: You might misunderstand the hardware problem i mention here. This soft IP controller is able to provide the ID for our Altera EPCS/EPCQ flash chips, which are non JEDEC chips. As from EPCQ device data sheet (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf), the device ID is 8 bit data. 8 bits of data is vastly insufficient for uniquely identifying a flash. This is not extendible and is not really a candidate for inclusion in mainline, unless it's somehow guaranteed that these flash can only be used with your controller (and I'm not sure how you would do that). Otherwise, you need to augment every flash with more out-of-band device-tree information. The remaining problem here is that this controller is able to support Micron chips but it currently has limitation in providing only 8 bit ID, which is not full JEDEC ID for Micron chips. You're just proving my point. I will not support READ ID detection that is based on only 8 bits of ID. Hence, we are asking hardware engineer to find out the solution so that the driver does not need to do any dirty hacking. OK, then I wish your hardware team great speed. And so, this table should still be here even hardware fix will take place or not. I'm not sure how you come to this conclusion. I have this conclusion is because Altera EPCQ/EPCS flashes are non JEDEC. Thus on the spi_device_id table, the ID in the INFO struct must be filled up with zeros in order to matches the current framework. However, since i still persist to have the device id check in my driver, as suggested by Rash, I should implement it locally in my driver. And this table is the look up table for the device ID of supported flashes. Or maybe you can give me any other better idea? BTW, to reiterate one other question that I feel wasn't adequately answered: what does the full ID string look like for these EPCS/EPCQ flash chips? Not the ID as seen by your limited controller, but the ID that can be reported by the flash chip. Is it really only an 8-bit number? Or does it have a longer string that your controller just can't read? Yes, As you can refer to page 32 of EPCQ flash datasheet (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf), This operation reads the 8-bit device identification of the EPCQ device from the DATA1 output pin. Table 29 lists the EPCQ device identifications Nga -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] dt-bindings: Create Documentation for NSP DT bindings
Add the documentation for the Broadcom Northstar Plus device tree bindings. Signed-off-by: Jon Mason jonma...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com --- .../devicetree/bindings/arm/bcm/brcm,nsp.txt | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt new file mode 100644 index 000..eae53e4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt @@ -0,0 +1,34 @@ +Broadcom Northstar Plus device tree bindings + + +Broadcom Northstar Plus family of SoCs are used for switching control +and management applications as well as residential router/gateway +applications. The SoC features dual core Cortex A9 ARM CPUs, integrating +several peripheral interfaces including multiple Gigabit Ethernet PHYs, +DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash, +SATA and several other IO controllers. + +Boards with Northstar Plus SoCs shall have the following properties: + +Required root node property: + +BCM58522 +compatible = brcm,bcm58522, brcm,nsp; + +BCM58525 +compatible = brcm,bcm58525, brcm,nsp; + +BCM58535 +compatible = brcm,bcm58535, brcm,nsp; + +BCM58622 +compatible = brcm,bcm58622, brcm,nsp; + +BCM58623 +compatible = brcm,bcm58623, brcm,nsp; + +BCM58625 +compatible = brcm,bcm58625, brcm,nsp; + +BCM88312 +compatible = brcm,bcm88312, brcm,nsp; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree
Add a very minimalistic set of Northstar Plus Device Tree files which
describes the SoC and the BCM958625 implementation. The perpherials
described are:
ARM Cortex A9 CPU
2 8250 UARTs
ARM GIC
PL310 L2 Cache
ARM A9 Global timer
Signed-off-by: Jon Mason jonma...@broadcom.com
Signed-off-by: Kapil Hali kap...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/bcm-nsp.dtsi | 105 +++
arch/arm/boot/dts/bcm958625k.dts | 57 +
3 files changed, 164 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
create mode 100644 arch/arm/boot/dts/bcm958625k.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..adb5732 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -82,6 +82,8 @@ dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
dtb-$(CONFIG_ARCH_BCM_MOBILE) += \
bcm28155-ap.dtb \
bcm21664-garnet.dtb
+dtb-$(CONFIG_ARCH_BCM_NSP) += \
+ bcm958625k.dtb
dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2-sony-nsz-gs7.dtb \
berlin2cd-google-chromecast.dtb \
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
new file mode 100644
index 000..77f9bfc
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -0,0 +1,105 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 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
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/interrupt-controller/irq.h
+
+#include skeleton.dtsi
+
+/ {
+ compatible = brcm,nsp;
+ model = Broadcom Northstar Plus SoC;
+ interrupt-parent = gic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ next-level-cache = L2;
+ reg = 0x0;
+ };
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ periph_clk: periph_clk {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 5;
+ };
+ };
+
+ uart0: serial@18000300 {
+ compatible = ns16550a;
+ reg = 0x18000300 0x100;
+ interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+ clock-frequency = 62499840;
+ status = disabled;
+ };
+
+ uart1: serial@18000400 {
+ compatible = ns16550a;
+ reg = 0x18000400 0x100;
+ interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+ clock-frequency = 62499840;
+ status = disabled;
+ };
+
+ gic: interrupt-controller@19021000 {
+ compatible = arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x19021000 0x1000,
+ 0x19020100 0x100;
+ };
+
+ L2: l2-cache {
+ compatible = arm,pl310-cache;
+ reg = 0x19022000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
+
Re: [PATCH 4/9] spi: sun4i: add DMA support
On Thu, Aug 20, 2015 at 02:19:46PM -, Emilio López wrote: Signed-off-by: Emilio López emi...@elopez.com.ar Tested-by: Michal Suchanek hramr...@gmail.com Also, if you're sending on a patch from someone else you must add a Signed-off-by, see SubmittingPatches. signature.asc Description: Digital signature
[PATCH 0/2] watchdog: driver for BCM7038 and newer chips.
This driver is for a watchdog block contained in all Broadcom Set-top Box chips since BCM7038. BCM7038 was made public during the 2004 CES, and since then, many chips use this watchdog block including some cable modem chips. Patch 1: watchdog device tree binding documentation Patch 2: watchdog driver Justin Chen (2): watchdog: bcm7038: add device tree binding documentation watchdog: Watchdog driver for Broadcom Set-Top Box .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 ++ drivers/watchdog/Kconfig | 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bcm7038_wdt.c | 253 + 4 files changed, 281 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt create mode 100644 drivers/watchdog/bcm7038_wdt.c -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe devicetree 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 4/4] spi: mediatek: revise coding style
On Thu, Aug 20, 2015 at 05:19:09PM +0800, Leilk Liu wrote: This patch revises littery coding style according to comments. I can't understand this commit log, sorry - what are the comments that are being addressed? - reg_val |= (((high_time - 1) 0xff) SPI_CFG0_SCK_HIGH_OFFSET); - reg_val |= (((low_time - 1) 0xff) SPI_CFG0_SCK_LOW_OFFSET); - reg_val |= (((holdtime - 1) 0xff) SPI_CFG0_CS_HOLD_OFFSET); - reg_val |= (((setuptime - 1) 0xff) SPI_CFG0_CS_SETUP_OFFSET); + reg_val |= (((sck_time - 1) 0xff) SPI_CFG0_SCK_HIGH_OFFSET); + reg_val |= (((sck_time - 1) 0xff) SPI_CFG0_SCK_LOW_OFFSET); + reg_val |= (((cs_time - 1) 0xff) SPI_CFG0_CS_HOLD_OFFSET); + reg_val |= (((cs_time - 1) 0xff) SPI_CFG0_CS_SETUP_OFFSET); This isn't a coding style change this is (I think) renaming a bunch of variables for some reason. signature.asc Description: Digital signature
Re: [PATCH 0/2] Add R8A7794/SILK I2C device tree support
On Thu, Aug 20, 2015 at 01:08:33AM +0300, Sergei Shtylyov wrote: On 08/20/2015 12:57 AM, Sergei Shtylyov wrote: Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20150819-v4.2-rc7' tag. Here we add the I2C device tree support for the R8A7794/SILK board. [1/2] ARM: shmobile: r8a7794: add I2C DT support [2/2] ARM: shmobile: silk: add I2C1 DT support Simon, actually the above patch is atop of my SILK SDHI1 patch but should apply with offsets atop of your tag. Thanks for following up. I have queued up this series for v4.4. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] watchdog: bcm7038: add device tree binding documentation
Add device tree binding docmentation for the watchdog hardware block
on bcm7038 and newer SoCs.
Signed-off-by: Justin Chen justinpo...@gmail.com
---
.../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..adb8260
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be brcm,bcm7038-wdt
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: the clock running the watchdog
+- clock-frequency: the rate of the clock
+
+Example:
+
+watchdog {
+ compatible = brcm,bcm7038-wdt;
+ clocks = upg_fixed;
+ reg = 0xf040a7e8 0x16;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Add Broadcom Northstar Plus Support
This patch series adds support for the Broadcom Northstar Plus family of SoCs. NSP is a Cortex A9 based SoC under the Broadcom iProc family. Jon Mason (5): dt-bindings: Create Documentation for NSP DT bindings ARM: NSP: add minimal Northstar Plus device tree ARM: NSP: Add basic support for Broadcom Northstar Plus SoC ARM: multi_v7_defconfig: Add NSP to defconfig MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs .../devicetree/bindings/arm/bcm/brcm,nsp.txt | 34 +++ MAINTAINERS| 12 ++- arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/bcm-nsp.dtsi | 105 + arch/arm/boot/dts/bcm958625k.dts | 57 +++ arch/arm/configs/multi_v7_defconfig| 1 + arch/arm/mach-bcm/Kconfig | 14 +++ arch/arm/mach-bcm/Makefile | 5 +- arch/arm/mach-bcm/bcm_nsp.c| 25 + 9 files changed, 252 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi create mode 100644 arch/arm/boot/dts/bcm958625k.dts create mode 100644 arch/arm/mach-bcm/bcm_nsp.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm64: dts: Add base stratix 10 dtsi
On 08/20/2015 12:23 PM, Mark Rutland wrote:
Hi,
+/ {
+compatible = altr,socfpga-stratix10;
+#address-cells = 1;
+#size-cells = 1;
I would recommend that you make your root #address-cells and #size-cells equal
to 2, as that will simplify matters later if/when you need to add anything
beyond the first 4GB for some particular board.
If everything in the SoC falls within the first 4GB you can have a ranges
property on your /soc node and have only one cell below that.
Ok, will update.
[...]
+intc: intc@8000 {
The unit-address doesn't match the first address in the reg entry.
Right, according to the GIC-400 r0p1 TRM, section 3.2 register map,
shows that
0x - 0x0fff Reserved
0x1000 - 0x1fff Distibutor
...
So even though the GIC address starts at 0x8000, the first usable
register is at 0x9000. I'll have to ask the hw folks if the
0x8000 represents the distributor or the reserved block.
+compatible = arm,gic-400, arm,cortex-a15-gic;
+#interrupt-cells = 3;
+interrupt-controller;
+reg = 0x0 0x9000 0x1000,
+ 0x0 0xa000 0x2000,
+ 0x0 0xc000 0x1000,
+ 0x0 0xd000 0x1000;
+};
Shouldn't the virtual CPU interface also be 0x2000 long?
Yes, it is. Will update
Thanks for reviewing.
Dinh
--
To unsubscribe from this list: send the line unsubscribe devicetree 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/9] spi: sun4i: add DMA support
On Thu, Aug 20, 2015 at 02:19:46PM -, Emilio López wrote:
- sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+ if (sun4i_spi_can_dma(master, spi, tfr) desc_rx) {
+ /* The receive transfer should be the last one to finish */
+ dma_wait_for_async_tx(desc_rx);
What if it's a transmit only transfer? We'll fall over to this...
+ } else {
+ sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+ }
...which manually reads data from the FIFO which doesn't seem like what
we want, won't it conflict with the DMA?
signature.asc
Description: Digital signature
Re: [PATCH v2 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup
On 08/17/2015 04:10 PM, Yingjoe Chen wrote:
On Thu, 2015-08-13 at 10:35 +0200, Daniel Lezcano wrote:
On 07/22/2015 10:14 AM, Yingjoe Chen wrote:
Spurious mtk timer interrupt is noticed at boot and cause kernel
crash. It seems if GPT is enabled, it will latch irq status even
when its IRQ is disabled.
It seems ?
When irq is enabled afterward, we see
spurious interrupt.
Doesn't have the firmware something to do with that ?
I have a mtk 8173 board I can use next week. How do you reproduce the
issue ?
Change init flow to only enable GPT_CLK_SRC at mtk_timer_init.
Acked-by: Matthias Brugger matthias@gmail.com
Reviewed-by: Daniel Kurtz djku...@chromium.org
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
Update to my patch [1], added __init as Daniel suggest. This is the
only patch that need to change in that series, so I only sent this one.
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001545.html
drivers/clocksource/mtk_timer.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 68ab423..2ba5b66 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -156,9 +156,11 @@ static void mtk_timer_global_reset(struct
mtk_clock_event_device *evt)
writel(0x3f, evt-gpt_base + GPT_IRQ_ACK_REG);
}
-static void
-mtk_timer_setup(struct mtk_clock_event_device *evt, u8 timer, u8 option)
+static void __init mtk_timer_setup(struct mtk_clock_event_device *evt,
+ u8 timer, u8 option, bool enable)
{
+ u32 val;
+
writel(TIMER_CTRL_CLEAR | TIMER_CTRL_DISABLE,
evt-gpt_base + TIMER_CTRL_REG(timer));
@@ -167,8 +169,10 @@ mtk_timer_setup(struct mtk_clock_event_device *evt, u8
timer, u8 option)
writel(0x0, evt-gpt_base + TIMER_CMP_REG(timer));
- writel(TIMER_CTRL_OP(option) | TIMER_CTRL_ENABLE,
- evt-gpt_base + TIMER_CTRL_REG(timer));
+ val = TIMER_CTRL_OP(option);
+ if (enable)
+ val |= TIMER_CTRL_ENABLE;
+ writel(val, evt-gpt_base + TIMER_CTRL_REG(timer));
Instead of the 'enable' new option, I prefer a test with 'timer' with a
comment:
/*
* the timer hw is broken in that way ... bla bla, so we only
* enable the clocksource ...
*/
if (timer == GPT_CLK_SRC)
val |= TIMER_CTRL_ENABLE;
Hi Daniel,
Thanks for your review.
Since this bug happens to anyone using interrupt,
Can you elaborate ? I don't get the point.
I'm not sure checking
timer and only enable it for GPT_CLK_SRC is easier to read. Anyway, I'll
change to this in next version.
That said, can you have a look at commit 1096be08 ?
clockevents: sun5i: Fix setup_irq init sequence
first and check if moving the interrupt request after the
clockevents_config_and_register could fix your issue.
I've tested this before, see:
http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000539.html
http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000551.html
I could take or ack this patch trusting it fixes the issue but there are
some points that need clarifications.
- Does the spurious interrupt occurs *every* time ? at each boot ?
The previous patches were supposed to fix the issue but they actually
didn't. So how is tested the patch ?
Regarding the different fixes for this problem, it sounds like you are
proceeding by trial and error.
Please give a more detailed analysis of the problem and especially check
the timer is not altered by the firmware leaving it in a transient state
or whatever.
-- Daniel
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH 4/9] spi: sun4i: add DMA support
On 20 August 2015 at 16:19, Emilio López emi...@elopez.com.ar wrote: From: Emilio López emi...@elopez.com.ar Something went wrong with overriding the headers Sorry Michal -- To unsubscribe from this list: send the line unsubscribe devicetree 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/9] spi: sunxi: fix transfer timeout
On Thu, Aug 20, 2015 at 02:19:45PM -, Michal Suchanek wrote:
The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
1MHz SPI bus takes way longer than that. Calculate the timeout from the
actual time the transfer is supposed to take and multiply by 2 for good
measure.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
drivers/spi/spi-sun4i.c | 10 +-
drivers/spi/spi-sun6i.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index fbb0a4d..48532ec 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -170,6 +170,7 @@ static int sun4i_spi_transfer_one(struct spi_master
*master,
{
struct sun4i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
+ unsigned int start, end, tx_time;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
@@ -279,9 +280,16 @@ static int sun4i_spi_transfer_one(struct spi_master
*master,
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
+ tx_time = max_t(int, tfr-len * 8 * 2 / (speed / 1000), 100);
+ start = jiffies;
timeout = wait_for_completion_timeout(sspi-done,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(tx_time));
+ end = jiffies;
if (!timeout) {
+ dev_warn(master-dev,
+ %s: timeout transferring %u bytes@%iHz for %i(%i)ms,
+ dev_name(spi-dev), tfr-len, speed,
+ jiffies_to_msecs(end - start), tx_time);
Timeout already contains the number of jiffies elapsed (and I'm not
sure anyone reading that message would get that the last number is
actually the maximum timeout).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v7 4/5] clk: Provide critical clock support
2015-08-17 15:42 GMT+08:00 Lee Jones lee.jo...@linaro.org:
On Mon, 17 Aug 2015, Barry Song wrote:
2015-07-22 21:04 GMT+08:00 Lee Jones lee.jo...@linaro.org:
Lots of platforms contain clocks which if turned off would prove fatal.
The only way to recover from these catastrophic failures is to restart
the board(s). Now, when a clock provider is registered with the
framework it is possible for a list of critical clocks to be supplied
which must be kept ungated. Each clock mentioned in the newly
introduced 'critical-clock' property will be clk_prepare_enable()d
where the normal references will be taken. This will prevent the
common clk framework from attempting to gate them during the normal
clk_disable_unused() and disable_clock() procedures.
Note that it will still be possible for knowledgeable drivers to turn
these clocks off using clk_{enable,disable}_critical() calls.
Signed-off-by: Lee Jones lee.jo...@linaro.org
hi Lee,
i have another email about this. i am wondering whether
CLK_IGNORE_UNUSE is still useful after your patch. another solution
for your patch might be extending the current CLK_IGNORE_UNUSE to
runtime?
copy the mail here:
currently we can set a CLK_IGNORE_UNUSE flag to a clock to stop
clk_disable_unused() from disabling it at the boot stage:
static void clk_disable_unused_subtree(struct clk_core *core)
{
...
if (core-flags CLK_IGNORE_UNUSED)
goto unlock_out;
}
static int clk_disable_unused(void)
{
...
clk_unprepare_unused_subtree(core);
...
return 0;
}
late_initcall_sync(clk_disable_unused);
so if there are two clocks A and B, A is the parent of B, and A is
marked as CLK_IGNORE_UNUSED.
in boot stage if there is nobody using A and B, Linux will disable B
due to clk_disable_unused() , but keep A being enabled since A has
CLK_IGNORE_UNUSED.
but in Linux runtime, we might frequently disable /enable B in runtime
power management, this will cause A disabled since Linux will not
check CLK_IGNORE_UNUSED for runtime disabling clk .
so this makes CLK_IGNORE_UNUSE only work if we don't disable its
sub-clock at runtime. this looks making no sense.
i am thinking whether we should do some changes to make it have side
affect for runtime clk disable. otherwise, why do we want to stop it
from being disabled during boot stage?
This is one of this problems, along with some others that this set
aims to solve.
Extending CLK_IGNORE_UNUSED is not a good idea. In fact, if we can
phase it out completely, that will be a good thing.
i would agree it is better we can drop CLK_IGNORE_UNUSED since it is
confusing...
Since this set Mike has submitted an alternitive solution.
Please see:
https://groups.google.com/forum/#!msg/linux.kernel/kX_nWSsWRxU/IZSjhG5Ed4oJ
I am not sure whether i missed something in clk core level support.
-barry
---
drivers/clk/clk-conf.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
index aad4796..f83c1c2 100644
--- a/drivers/clk/clk-conf.c
+++ b/drivers/clk/clk-conf.c
@@ -116,6 +116,45 @@ static int __set_clk_rates(struct device_node *node,
bool clk_supplier)
return 0;
}
+static int __set_critical_clocks(struct device_node *node, bool
clk_supplier)
+{
+ struct of_phandle_args clkspec;
+ struct clk *clk;
+ struct property *prop;
+ const __be32 *cur;
+ uint32_t index;
+ int ret;
+
+ if (!clk_supplier)
+ return 0;
+
+ of_property_for_each_u32(node, critical-clock, prop, cur, index)
{
+ clkspec.np = node;
+ clkspec.args_count = 1;
+ clkspec.args[0] = index;
+
+ clk = of_clk_get_from_provider(clkspec);
+ if (IS_ERR(clk)) {
+ pr_err(clk: couldn't get clock %u for %s\n,
+ index, node-full_name);
+ return PTR_ERR(clk);
+ }
+
+ clk_init_critical(clk);
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err(Failed to enable clock %u for %s: %d\n,
+ index, node-full_name, ret);
+ return ret;
+ }
+
+ pr_debug(Setting clock as critical %pC\n, clk);
+ }
+
+ return 0;
+}
+
/**
* of_clk_set_defaults() - parse and set assigned clocks configuration
* @node: device node to apply clock settings for
@@ -139,6 +178,10 @@ int of_clk_set_defaults(struct device_node *node,
bool clk_supplier)
if (rc 0)
return rc;
- return __set_clk_rates(node, clk_supplier);
+ rc = __set_clk_rates(node, clk_supplier);
+ if (rc 0)
+ return rc;
Re: [PATCH v2 2/3] mailbox: Hi6220: add mailbox driver
Hi Yiping,
Thanks for review, please see below comments.
On Thu, Aug 20, 2015 at 01:42:58PM +0800, YiPing Xu wrote:
On 2015/8/20 10:53, Leo Yan wrote:
Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message; enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.
Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.
Signed-off-by: Leo Yan leo@linaro.org
[...]
+static int hi6220_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+struct hi6220_mbox_chan *mchan = chan-con_priv;
+struct hi6220_mbox *mbox = mchan-parent;
+int irq = mchan-remote_irq;
+u32 *buf = msg;
+unsigned long flags;
+int i;
+
+hi6220_mbox_set_status(mchan, HI6220_MBOX_STATUS_TX);
hi6220_mbox_set_status is called in send_data context, and it is
also called in hi6220_mbox_rx_interrupt and
hi6220_mbox_tx_interrupt.
no race condition here?
Have thought this question yet when writing code; it will _NOT_
introduce race condition according to below implementation details:
- Every channel have its own slot, so there have no race condition
between channels;
- The channel is unidirectional; so it will be only for tx or rx at
the same time;
- The channel operation is sequential, so it have the sequence as:
For tx: startup - send_data - tx_irq (for ack);
For rx: startup - rx_irq - recv_data;
Thanks,
Leo Yan
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 00/16] omap_hsmmc: regulator usage cleanup and fixes
Hi, On Monday 03 August 2015 05:56 PM, Kishon Vijay Abraham I wrote: Changes from v1: *) return on -EPROBE_DEFER and other fatal errors. (Don't return only if the return value is -ENODEV) *) Remove the beagle x15 dts patch. It can be part of a different series. *) Avoid using regulator_is_enabled for vqmmc since if the regulator is shared and the other users are not using regulator_is_enabled then there can be unbalanced regulator_enable/regulator_disable This patch series does the following *) Uses devm_regulator_get_optional() for vmmc and then removes the CONFIG_REGULATOR check altogether. *) return on -EPROBE_DEFER and any other fatal errors *) enable/disable vmmc_aux regulator based on prior state I've pushed this patch series to git://git.ti.com/linux-phy/linux-phy.git mmc_regulator_cleanup_fixes_v2 Please note the branch also has the pbias fixes [1] [2]. [1] - https://lkml.org/lkml/2015/7/27/358 [2] - https://lkml.org/lkml/2015/7/27/391 This series is in preparation for implementing the voltage switch sequence so that UHS cards can be supported. Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. I have now done read/write test in omap3 beagle-xm with this series! Thanks Kishon Kishon Vijay Abraham I (15): mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get() mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage mmc: host: omap_hsmmc: return error if any of the regulator APIs fail mmc: host: omap_hsmmc: add separate functions for enable/disable supply mmc: host: omap_hsmmc: add separate function to set pbias mmc: host: omap_hsmmc: avoid pbias regulator enable on power off mmc: host: omap_hsmmc: don't use -set_power to set initial regulator state mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on previous state mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status mmc: host: omap_hsmmc: use ios-vdd for setting vmmc voltage mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check Roger Quadros (1): mmc: host: omap_hsmmc: use mmc_of_parse_voltage to get ocr_avail .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 + drivers/mmc/host/omap_hsmmc.c | 340 +--- 2 files changed, 224 insertions(+), 118 deletions(-) -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
On Tuesday, August 18, 2015 at 04:47:35 AM, Brian Norris wrote:
Hi!
[...]
The only bizzare thing is this stuff above ^ . If I want to pass for
example m25p,fast-read to the SPI NOR connected to this controller, I
have to set
Do we really want to extend m25p80 properties like 'm25p,fast-read' to
all SPI NOR controllers? Are they necessary? It seems that there has
been some attempt to do so, but I'm not sure if that's by good design or
just by accident.
I guess we might want to support at least the m25p,fast-read prop.
I think it might be a good idea to let the SPI NOR framework parse
the common props, while also let the SPI NOR controller drivers parse
whatever props they need.
up the nor-dev-of_node, otherwise the of_node would point to the
controller. I am positive this is wrong, but I'm not quite sure how to
repair this. Brian, can you please comment on this one bit ?
The problem is that spi_nor_scan() is assuming that nor-dev represents
a flash device, not a flash controller (to which we might connect
multiple flash). So we need to provide a way for spi_nor_scan() to find
the flash device_node, not the controller device_node. Easy option:
Right.
(a) add a field to struct spi_nor, like I did to nand_chip [1]; e.g.,
spi_nor::dn.
In doing that, we might then reevaluate what spi_nor::dev is supposed to
mean (and clarify the doc comments in include/linux/mtd/spi-nor.h
accordingly). Currently, it's used to shoe-horn in DT support (badly),
as well as to provide mostly auxiliary info, like naming, debug info
(dev_{dbg,info,err,etc...}()), and simliar. The latter half can actually
be problematic too, since they start to become less useful once you have
more than one flash connected to a single controller. e.g., you'll get
colliding MTD names (via dev_name(nor-dev)) and debug info is suddenly
less obvious (which flash chip is the log message from?).
Right. Would it make sense to have one device per one SPI NOR flash and
then another one for the controller ?
So, we might want to do something in the long run to avoid the mixing of
layers that looks more like:
(b) remove 'dev' from struct spi_nor entirely
We can do debug prints and such with spi-nor-specific printk()
formatters (e.g., snor_{info,dbg,err,etc...}()) and stop assuming that
dev_name(nor-dev) is actually a good name for an MTD.
I cannot say I'm very fond of introducing new ad-hoc kernel printing
facility just for the sake of dealing with this.
While we're at it... we may also want a larger rework to allow spi-nor.c
to better support a notion of controllers (using the existing platform
device) and flash devices (mostly without the use of struct device, and
mostly using struct spi_nor as-is).
See my question about the devices above please, I'm not quite sure here.
You'll notice that controllers that
want to support multiple flash are starting to develop much of the same
initialization boiler-plate code.
Yep, I tweaked the Cadence driver such, that the boilerplate code is nicely
isolated in a separate function now, so this would also be visible :)
Anyway, that's my rambling thoughts for now. I think (a) is pretty
straightforward, correct, and quickly attainable
I just did that, it was a couple lines of code. I think I need to write a
better commit message for it before I send it out.
so you can ignore the
remaining bits in the context of upstreaming this driver.
Brian
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id
=5844feeaa4154d1c46d3462c7a4653d22356d8b4
--
To unsubscribe from this list: send the line unsubscribe devicetree 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/9] spi: sunxi: fix transfer timeout
On Thu, Aug 20, 2015 at 09:34:33PM +0200, Maxime Ripard wrote: On Thu, Aug 20, 2015 at 11:41:32AM -0700, Mark Brown wrote: On Thu, Aug 20, 2015 at 02:19:45PM -, Michal Suchanek wrote: drivers/spi/spi-sun4i.c | 10 +- drivers/spi/spi-sun6i.c | 10 +- Are we *sure* we can't work on merging these drivers :( Those are two different IPs, that don't really share anything but their author... I seem to be seeing a number of changes like this one which make apparently very similar modifications to both. Perhaps there is more core usage that should be happening instead? signature.asc Description: Digital signature
