RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>From: Ezequiel Garcia [mailto:ezequ...@vanguardiasur.com.ar]
>>On 24 Jun 05:54 PM, Pekon Gupta wrote:
>> +&gpmc {
>> +ranges = <0 0 0 0x0100>;/* address range = 16MB (minimum GPMC
>> partition) */
>> +nand@0,0 {
>> +status = "disabled";
>> +reg = <0 0 4>; /* device IO registers */
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&bbcape_nand_flash_pins>;
>> +ti,nand-ecc-opt = "bch8";
>> +ti,elm-id = <&elm>;
>
>Don't you need something like this to turn on the elm device?
>
>&elm {
> status = "okay";
>};
>
No, This was the intend of these patches to keep cape DTS as "disabled"
so that:
(1)These patches should not change the behavior of existing DTS
(am335x-boneblack.dts or am335x-bone.dts), or conflict with
any existing node or other cape DTS.
(2) In-case of share-pin mux where multiple capes use same pins
Cape DTS should not conflict each other.
Now, to enable the choice of cape without hacking any source file,
user can use u-boot commands (refer to example in cover-letter):
/* load DTB */
u-boot> tftp 0x8100 am335x-boneblack.dtb
u-boot> fdt addr 0x8100
/* disabled conflicting MMC2 (eMMC) */
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
/* enable NAND cape*/
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt set /ocp/gpmc/nand status \o\k\a\y
And then boot using this DTB loaded at 0x8100
(you can put all these commands in uEnv as part of $bootcmd)
with regards, Pekon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
On Wed, Jun 25, 2014 at 1:49 AM, Gupta, Pekon wrote:
>>From: Jason Kridner [mailto:jkrid...@gmail.com]
>>On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta wrote:
>>> This patch adds support for LCD4 cape as advertised on
>>> http://elinux.org/CircuitCo:BeagleBone_LCD4
> [...]
>
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts
>>> b/arch/arm/boot/dts/am335x-bone-
>>display-cape.dts
>>
>>If this is mean to be included, why not use the .dtsi extension rather
>>than .dts. .dts implies it is a top-level file.
>>
> I followed the ideology given in in below discussion
> http://comments.gmane.org/gmane.linux.drivers.devicetree/13921
>
> As I understood .dtsi file extension should be used for silicon DT data which
> which remains common for all the boards using that silicon (like am33xx.dtsi).
> And .dts is for board specific DT data.
> However, anything works for me, as its just matter of file-name-extension.
> So should I rename all files to .dtsi ?
I believe the thread is not thinking of "board-level" as being add-on
boards. I don't think it disagrees that if it is an include file, it
should be called .dtsi. If it is called .dts, the assumption should be
that it results in a .dtb (or .dtbo if for an overlay --- not yet a
solution in mainline).
>
> [...]
>
>>> +/ {
>>> + backlight {
>>> + status = "disabled";
>>> + compatible = "gpio-backlight";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&bbcape_backlight_pins>;
>>> + gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
>>> + default-on;
>>> + };
>>> +
>>> + panel {
>>> + status = "disabled";
>>
>>Where are you expecting to enable this? I'm guessing through your
>>u-boot hacking? Certainly I can see editing the boot script to make
>>this work, but I don't see how this results in the average user simply
>>plugging in the cape and having it work without having to edit files.
>>
> Yes, using u-boot commands, *without touching any source file*.
> I'm planning to send patch for adding following helper commands in u-boot
> u-boot> fdt node enable
> u-boot> fdt node disable
> If that's accepted, enabling disabling capes will become very easy.
> And, as you said user can put these commands in scripts (like Uenv.txt)
> or environment variable, and execute them automatically at each boot.
>
>
>>Perhaps you can put some real logic into the bootloader that looks at
>>the cape EEPROMs?
>>
> No, I don't want to go the EEPROM way, because of reasons suggested
> in earlier mail. It's not scalable, especially when you don't have control
> over what type and how third-party is developing the capes.
Well, I have no interest in needing to manually switch my uEnv.txt
file based on whatever cape I have installed. Your patches to put
by-default-disabled disabled support for various capes into the the
main .dtb feels useful to me. I'm just going to optimize my systems to
utilize the EEPROM (when provided) to trigger loading the
configuration for me.
>
>
>>Have you considered using tools like pinmux-helper as is done with the
>>cape-universal overlay?
>>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
>>00A0.dts
>>
> Yes, I have seen that. In pin-mux helper pins are configured not based on
> their actual names but as they appear on P8 and P9 headers of Beaglebone.
> - For shared pins, you have defined all possible functionality.
> - For dedicated pins, there is single fragment.
> Now there are two questions..
> (1) Do we need to update this cape-universal-xx.dts everytime a new
> Cape in market uses some dedicated pin for some muxed functionality ?
cape-universalXXX.dts needs to be moved into the main .dtb (via
.dtsi). Can you give an example of what you mean by shared pins and
dedicated pins here? It seems to me all the pins have multiple
fragments except ADC pins and perhaps the I2C port used for expansion
EEPROMs, but even that one CAN be muxed.
> (2) I'm not sure but kernel does _not_ free the memory allocated to
> DT fragment. If so, this universal fragment which has pin-mux for all
> P8 and P9 pins will block the memory forever. Would be good to know
> the in-memory size required for this universal fragment ?
How can I check easily? Obviously loading all of these drivers is
going to have an impact.
>
>
>>I've been hacking with adding all of these pinmux helpers to the main
>>.dts. I think you are encouraging me to add it to include files to
>>make it a bit more granular.
>>
>>http://paste.debian.net/106319/
>>
> Yes, using include files would be good.
> Also one minor feedback. Please use macros for Pin directions, Pulls, etc
> instead of hex numbers, it make it more readable. And then you don't need
> to specify that in comments.
> - 0xa0 0x08/* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT |
> AM33XX_PULL_DISA */
> + 0xa0 (OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)
Re: [PATCH] ARM: DRA7-evm: Enable SATA PHY and USB PHY power supplies
On 06/25/2014 07:56 AM, Roger Quadros wrote:
> The SATA and USB PHYs need the 1.8V and 3.3V supplies.
> The PHY drivers/framework don't yet support regulator
> supply so we have to keep these regulators always-on till
> then.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/dra7-evm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 4adc280..99a1f79 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -241,6 +241,7 @@
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
> regulator-boot-on;
> + regulator-always-on;
> };
>
> ldo9_reg: ldo9 {
> @@ -266,6 +267,7 @@
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> regulator-boot-on;
> + regulator-always-on;
> };
> };
> };
>
Why not fix phy driver/framework as needed? the trouble is people
always forget to remove always-on... who actually audits old logs and
fixes stuff back up?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
On Tue, 24 Jun 2014, Suman Anna wrote:
> The legacy-style definition of the hwmod addr space is no longer
> required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
> DT nodes have been added, so clean up this data.
>
> Cc: Paul Walmsley
> Signed-off-by: Suman Anna
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
> index e2db378..8f5989d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
> @@ -317,21 +317,11 @@ struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
> .user = OCP_USER_MPU,
> };
>
> -static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
> - {
> - .pa_start = 0x480C8000,
> - .pa_end = 0x480C8000 + (SZ_4K - 1),
> - .flags = ADDR_TYPE_RT
> - },
> - { }
> -};
> -
> /* l4 ls -> mailbox */
> struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
> .master = &am33xx_l4_ls_hwmod,
> .slave = &am33xx_mailbox_hwmod,
> .clk= "l4ls_gclk",
> - .addr = am33xx_mailbox_addrs,
> .user = OCP_USER_MPU,
> };
Acked-by: Paul Walmsley
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
On Tue, 24 Jun 2014, Suman Anna wrote:
> OMAP2 devices are devicetree boot only, and the legacy mode
> of mailbox device creation should no longer be used, so remove
> the mailbox attribute data and the hwmod addr space used for
> creating mailboxes in legacy mode.
>
> Cc: Paul Walmsley
> Signed-off-by: Suman Anna
Acked-by: Paul Walmsley
- Paul
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14
> --
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
> .../mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c| 9 -
> arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 -
> 4 files changed, 37 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index 2f15979..65b1647 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -16,7 +16,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "omap_hwmod.h"
> @@ -163,18 +162,6 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
> };
>
> /* mailbox */
> -static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
> - { .name = "dsp", .tx_id = 0, .rx_id = 1, .irq_id = 0, .usr_id = 0 },
> - { .name = "iva", .tx_id = 2, .rx_id = 3, .irq_id = 1, .usr_id = 3 },
> -};
> -
> -static struct omap_mbox_pdata omap2420_mailbox_attrs = {
> - .num_users = 4,
> - .num_fifos = 6,
> - .info_cnt = ARRAY_SIZE(omap2420_mailbox_info),
> - .info = omap2420_mailbox_info,
> -};
> -
> static struct omap_hwmod omap2420_mailbox_hwmod = {
> .name = "mailbox",
> .class = &omap2xxx_mailbox_hwmod_class,
> @@ -188,7 +175,6 @@ static struct omap_hwmod omap2420_mailbox_hwmod = {
> .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
> },
> },
> - .dev_attr = &omap2420_mailbox_attrs,
> };
>
> /*
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 6d1b609..c2555cb 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "omap_hwmod.h"
> @@ -161,17 +160,6 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
> };
>
> /* mailbox */
> -static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
> - { .name = "dsp", .tx_id = 0, .rx_id = 1 },
> -};
> -
> -static struct omap_mbox_pdata omap2430_mailbox_attrs = {
> - .num_users = 4,
> - .num_fifos = 6,
> - .info_cnt = ARRAY_SIZE(omap2430_mailbox_info),
> - .info = omap2430_mailbox_info,
> -};
> -
> static struct omap_hwmod omap2430_mailbox_hwmod = {
> .name = "mailbox",
> .class = &omap2xxx_mailbox_hwmod_class,
> @@ -185,7 +173,6 @@ static struct omap_hwmod omap2430_mailbox_hwmod = {
> .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
> },
> },
> - .dev_attr = &omap2430_mailbox_attrs,
> };
>
> /* mcspi3 */
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
> index 0413dab..c1e98d5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
> @@ -152,15 +152,6 @@ struct omap_hwmod_addr_space omap2_dma_system_addrs[] = {
> { }
> };
>
> -struct omap_hwmod_addr_space omap2_mailbox_addrs[] = {
> - {
> - .pa_start = 0x48094000,
> - .pa_end = 0x48094000 + SZ_512 - 1,
> - .flags = ADDR_TYPE_RT,
> - },
> - { }
> -};
> -
> struct omap_hwmod_addr_space omap2_mcbsp1_addrs[] = {
> {
> .name = "mpu",
> diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
> b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> index 2c38c6b..11ed5a1 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> @@ -33,7 +33,6 @@ extern struct omap_hwmod_addr_space
> omap2_mcspi1_addr_space[];
> extern struct omap_hwmod_addr_space omap2_mcspi2_addr_space[];
> extern struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[];
> extern struct omap_hwmod_addr_space omap2_dma_system_addrs[];
> -extern struct omap_hwmod_addr_space omap2_mailbox_addrs[];
> extern struct omap_hwmod_addr_space omap2_mcbsp1_addrs[];
> extern struct omap_hwmod_addr_space omap2_hdq1w_addr_space[];
>
> --
> 2.0.0
>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.
Cc: Tony Lindgren
Cc: Russell King
Cc: Paul Walmsley
Signed-off-by: Kishon Vijay Abraham I
Tested-by: Kishon Vijay Abraham I
---
Please find the bootlog with these hwmod patches
http://paste.ubuntu.com/7701601/
arch/arm/mach-omap2/cm2_7xx.h |4 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 57 +
arch/arm/mach-omap2/prm7xx.h |4 ++
3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
index 9ad7594..e966e3a 100644
--- a/arch/arm/mach-omap2/cm2_7xx.h
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -357,6 +357,10 @@
#define DRA7XX_CM_L3INIT_SATA_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
#define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET0x00a0
#define DRA7XX_CM_PCIE_STATICDEP_OFFSET0x00a4
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET0x00b0
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b0)
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET0x00b8
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b8)
#define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET0x00c0
#define DRA7XX_CM_GMAC_STATICDEP_OFFSET0x00c4
#define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET 0x00c8
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 3deb76e..6ff40a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,45 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE PHY' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
+ .name = "pcie-phy",
+};
+
+/* pcie1 phy */
+static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
+ .name = "pcie1-phy",
+ .class = &dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 phy */
+static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
+ .name = "pcie2-phy",
+ .class = &dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'qspi' class
*
*/
@@ -2409,6 +2448,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> pcie1 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie1_phy_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2_phy = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie2_phy_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2758,6 +2813,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
&dra7xx_l4_cfg__ocp2scp3,
+ &dra7xx_l4_cfg__pcie1_phy,
+ &dra7xx_l4_cfg__pcie2_phy,
&dra7xx_l3_main_1__qspi,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
index d92a840..4bb50fbf 100644
--- a/arch/arm/mach-omap2/prm7xx.h
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -374,6 +374,10 @@
#define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET 0x007c
#define DRA7XX_PM_L3INIT_SATA_WKDEP_OFFSET 0x0088
#define DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET 0x008c
+#define DRA7XX_PM_L3INIT_PCIESS1_WKDEP_OFFSET 0x00b0
+#def
[PATCH 0/2] arm: hwmod: dra7: Add PCIe data and PCIe PHY data
[1] is split into separate series in order for individual subsystem Maintainers to pick up the patches. This series handles the PCIe hwmod data for DRA7. Please find the bootlog with these hwmod patches @ [2] [1] -> https://lkml.org/lkml/2014/5/29/258 [2] -> http://paste.ubuntu.com/7701601/ Kishon Vijay Abraham I (2): arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems arch/arm/mach-omap2/cm2_7xx.h |4 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 112 + arch/arm/mach-omap2/prm7xx.h |4 ++ 3 files changed, 120 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Cc: Tony Lindgren
Cc: Russell King
Cc: Paul Walmsley
Signed-off-by: Kishon Vijay Abraham I
Tested-by: Kishon Vijay Abraham I
---
Please find the bootlog with these hwmod patches
http://paste.ubuntu.com/7701601/
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 6ff40a6..934aa9d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = "pcie",
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = "pcie1",
+ .class = &dra7xx_pcie_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = "pcie2",
+ .class = &dra7xx_pcie_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2448,6 +2485,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie1_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie2_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg -> pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = &dra7xx_l4_cfg_hwmod,
@@ -2813,6 +2866,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
&dra7xx_l4_cfg__ocp2scp3,
+ &dra7xx_l4_cfg__pcie1,
+ &dra7xx_l4_cfg__pcie2,
&dra7xx_l4_cfg__pcie1_phy,
&dra7xx_l4_cfg__pcie2_phy,
&dra7xx_l3_main_1__qspi,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
On Wednesday 18 June 2014 05:46 PM, Roger Quadros wrote:
> This module is needed for the SATA and PCIe PHYs.
>
> Signed-off-by: Roger Quadros
> Tested-by: Roger Quadros
I used this patch for testing PCIe.
Tested-by: Kishon Vijay Abraham I
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 20b4398..cedef6b 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
> },
> };
>
> +/* ocp2scp3 */
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
> +
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
> + .master = &dra7xx_l4_cfg_hwmod,
> + .slave = &dra7xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &dra7xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> /*
> * 'qspi' class
> *
> @@ -2672,6 +2696,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_per1__mmc4,
> &dra7xx_l4_cfg__mpu,
> &dra7xx_l4_cfg__ocp2scp1,
> + &dra7xx_l4_cfg__ocp2scp3,
> &dra7xx_l3_main_1__qspi,
> &dra7xx_l4_cfg__sata,
> &dra7xx_l4_cfg__smartreflex_core,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] mailbox/omap: add a custom of_xlate function
Hi Arnd,
On 06/25/2014 03:39 AM, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
>> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller
>> *controller,
>> + const struct of_phandle_args *sp)
>> +{
>> + phandle phandle = sp->args[0];
>> + struct device_node *node;
>> + struct omap_mbox_device *mdev;
>> + struct omap_mbox *mbox;
>> +
>> + node = of_find_node_by_phandle(phandle);
>> + if (!node) {
>> + pr_err("could not find node phandle 0x%x\n", phandle);
>> + return NULL;
>> + }
>> +
>> + mdev = container_of(controller, struct omap_mbox_device, controller);
>> + if (WARN_ON(!mdev))
>> + return NULL;
>> +
>> + mbox = omap_mbox_device_find(mdev, node->name);
>> + return mbox ? mbox->chan : NULL;
>>
>
> Wouldn't it be easier to change the omap_mbox_device_find() function to
> take a phandle argument directly? You shouldn't have to walk all
> nodes in the system, or match it by name if you already have the
> device node.
The omap_mbox_device_find() function is also used on the non-DT mailbox
client path (for OMAP3) at the moment where we don't have the device
node pointers. I am merely reusing the function for the DT lookup path,
and once I remove the non-DT support, I can surely do the matching logic
just based on the device node pointer. I just chose to minimize the
changes to the omap_mbox_device_find() to do both variants now when I
know that I am gonna remove the non-DT part (name lookup) later on.
The current expected DT usage model for the OMAP mailbox client is (with
the v7 mailbox framework)
mbox = <&controller_phandle &channel_phandle>
So, this is not walking through all the nodes in the system, only the
channel/sub-mailbox nodes present on the particular controller node.
Surely, it can done as mbox = <&channel_phandle> as the parent
controller node relationship is inherent, but this requires changes to
the mailbox framework, and I am not sure if every platform
implementation would implement the child channels as their own nodes.
>
> Also, the xlate function is normally the place where you read out
> the other arguments and set them as members in your omap_mbox
> structure.
The current flow for the xlate function is during the
mailbox_request_channel. The channels themselves would have been
registered during the controller node probe, so this is merely a lookup
for the correct channel. Should we be renaming the xlate function, if
the behavior is not what one expects out of a standard xlate?
regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
Hi Russell, On 25 Jun 03:46 PM, Russell King - ARM Linux wrote: > > > > That doesn't make any sense. Using late_initcall for the tilcdc DRM > > driver would make the tilcdc DRM get probed before any other regular > > module_init driver, including the tda998x encoder. > > A module_init() is a device_initcall(), which is at level 6. A > late_initcall() is at level 7. Level 6 initcalls are run before level > 7 initcalls. The tda998x is a module_init(), so the tda998x gets > initialised *before* tilcdc's late_initcall(). > Oh, thanks a lot for correcting me. > Now, if you build everything as a module, then you have no initialisation > ordering, and you can't rely on any kind of order. Initialisation > functions can even run in parallel on different CPUs due to modules being > loaded from userspace in a multi-threaded way. So anything which relies > on a certain initcall ordering is fundamentally broken if it can be > modular. > OK, but is there any outstanding issue with the tilcdc initialization, either when compiled as built-in or as modules, *after* this patchset? Of course, this driver only worked as built-in (see the horrible bugs we are fixing here, that prevented unloading and re-loading it). This series fixes all such bugs, and also adds the required changes to allow to build everything as a module. Again, I can't see any issues that remain to be fixed after this patchset. When compiled as built-in, the tilcdc DRM will be defered and once the tda998x is ready, the tilcdc DRM will load properly. When compiled as module you can load any of them in any order. If the tda998x module is not loaded by the time you load the tilcdc module, the former will get loaded. Hm... now that I think about this. We still get into trouble if the tda998x is built as module, but the tilcdc is built-in. Shouldn't we just forbid that? Either both built-ins or both as modules? > > > There's a solution to that... > > > > A solution to *what* ? > > Maybe if you left the context above that line in place, you might > understand that my "that" refers to what was discussed in that > context. That being the initialisation ordering. > > Convention and proper Internet etiquette is to trim the quoted text > and place relies below the paragraph to which they refer, the quoted > paragraph giving the context to the reply. > Yeah, sorry about that. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
On 25.06.2014 16:37, Russell King - ARM Linux wrote: > On Wed, Jun 25, 2014 at 04:13:16PM +0200, Tomasz Figa wrote: >> On 25.06.2014 15:50, Russell King - ARM Linux wrote: >>> On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: This series intends to add support for L2 cache on Exynos4 SoCs on boards running under secure firmware, which requires certain initialization steps to be done with help of firmware, as selected registers are writable only from secure mode. >>> >>> What I said in my message on June 12th applies to this series. I'm >>> not having the virtual address exposed via the write_sec call. >>> >>> Yes, you need to read other registers in order to use your secure >>> firmware implementation. Let's fix that by providing a better write_sec >>> interface so you don't have to read back these registers, rather than >>> working around this short-coming. >> >> Do you have anything in particular in mind? I would be glad to implement >> it and send patches. > > As I've already said, you are not the only ones who need fuller information > to make your secure monitor calls. So, what that implies is that rather > than the interface being "please write register X with value V", and then > having platforms work-around that by reading various registers, we need > a more flexible interface which passes the desired state. > So it's still not clear to me how this should be done correctly. One thing that comes to my mind is precomputing register values to some kind of structure, then calling some kind of magical platform-specific .enable() or .configure() callback, which takes the structure and, in one shot, configures the L2C according to firmware requirements. Then the generic code would read back those values to verify the final configuration (as it does right now) and rest of the operation would be identical. Is this something you would deem acceptable? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 24 Jun 05:54 PM, Pekon Gupta wrote:
> +&gpmc {
> + ranges = <0 0 0 0x0100>;/* address range = 16MB (minimum GPMC
> partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
> + pinctrl-names = "default";
> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
Don't you need something like this to turn on the elm device?
&elm {
status = "okay";
};
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
On 25 Jun 04:38 AM, Gupta, Pekon wrote: > >From: Ezequiel Garcia > >>On 24 Jun 05:54 PM, Pekon Gupta wrote: > >> This patch adds support for LCD4 cape as advertised on > >> http://elinux.org/CircuitCo:BeagleBone_LCD4 > >> > >> This cape has: > >> * 480x272 TFT-LCD panel > >> - LCD panel datasheet and timing information are sourced from [1] > >> - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for > >>enabling backlight power-supply. So 'gpio-backlight' driver is used > >> instead > >>of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y). > >> > > > >I'm confused about this, can you clarify why you are not using pwm-backlight? > > > > As per the schematics of this LCD4 cape board, "EHRPWM1A" pin controls > enabling/disabling of the power to backlight LED. It does not control the > voltage levels (brightness levels) of the LED. Thus it wasn't making sense > to use pwm-backlight driver which more suitable in cases where you have > multiple levels of brightness. > Here, you have only 2 levels "backlight=off | on", so I used gpio-backlight > driver. > Though you can use pwm-backlight driver also, but the backlight turns ON > only when you set the /sys/class/backlight//brighteness > to maximum level (as set in DT). > Hm, I didn't know that. Thanks for this information. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls
On 24 Jun 05:06 PM, Darren Etheridge wrote: > > On 06/17/2014 09:17 AM, Guido Martínez wrote: > >The TI tilcdc driver is designed with a notion of submodules. Currently, > >at unload time, these submodules are iterated and destroyed. > > > >Now that the tilcdc remove order is fixed, this can be handled perfectly > > I am not sure I understand the first part of the above sentence - did > something change with tilcdc ordering? Yes, patch [PATCH/RESEND 6/9] drm/tilcdc: fix release order on exit changes the tilcdc remove ordering. Currently, the tilcdc DRM is removed with this: tilcdc_tfp410_fini(); tilcdc_slave_fini(); tilcdc_panel_fini(); platform_driver_unregister(&tilcdc_platform_driver); Which is wrong as you shouldn't remove the tilcdc "modules" (panel, slave, tfp410) before the DRM driver itself. So the above patch fixed it to be: platform_driver_unregister(&tilcdc_platform_driver); tilcdc_panel_fini(); tilcdc_slave_fini(); tilcdc_tfp410_fini(); > I think you a referring to previous > patches in your series which really mean tilcdc can actually unload now. So > really the method this patch uses could always have been used, it just > wasn't for some reason? > No, I believe this patch which removes the tilcdc sub-module destroy infrastructure can only be applied *after* the above remove order is fixed (iow, the 6/9 patch mentioned above). In other words, only once you have a proper remove() that releases things in the right order you can rely in the kernel and avoid any custom implementation. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
On Wed, Jun 25, 2014 at 11:32:46AM -0300, Ezequiel García wrote: > (Ccing Guido back) > > Hello Russell, Darren, > > On 25 Jun 02:00 PM, Russell King - ARM Linux wrote: > > On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote: > > > If I recall, the late_initcall stuff was done to try and make sure the > > > tda998x/i2c subsystem came up before tilcdc. > > That doesn't make any sense. Using late_initcall for the tilcdc DRM > driver would make the tilcdc DRM get probed before any other regular > module_init driver, including the tda998x encoder. A module_init() is a device_initcall(), which is at level 6. A late_initcall() is at level 7. Level 6 initcalls are run before level 7 initcalls. The tda998x is a module_init(), so the tda998x gets initialised *before* tilcdc's late_initcall(). Now, if you build everything as a module, then you have no initialisation ordering, and you can't rely on any kind of order. Initialisation functions can even run in parallel on different CPUs due to modules being loaded from userspace in a multi-threaded way. So anything which relies on a certain initcall ordering is fundamentally broken if it can be modular. > > There's a solution to that... > > A solution to *what* ? Maybe if you left the context above that line in place, you might understand that my "that" refers to what was discussed in that context. That being the initialisation ordering. Convention and proper Internet etiquette is to trim the quoted text and place relies below the paragraph to which they refer, the quoted paragraph giving the context to the reply. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
On Wed, Jun 25, 2014 at 04:13:16PM +0200, Tomasz Figa wrote: > On 25.06.2014 15:50, Russell King - ARM Linux wrote: > > On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: > >> This series intends to add support for L2 cache on Exynos4 SoCs on boards > >> running under secure firmware, which requires certain initialization steps > >> to be done with help of firmware, as selected registers are writable only > >> from secure mode. > > > > What I said in my message on June 12th applies to this series. I'm > > not having the virtual address exposed via the write_sec call. > > > > Yes, you need to read other registers in order to use your secure > > firmware implementation. Let's fix that by providing a better write_sec > > interface so you don't have to read back these registers, rather than > > working around this short-coming. > > Do you have anything in particular in mind? I would be glad to implement > it and send patches. As I've already said, you are not the only ones who need fuller information to make your secure monitor calls. So, what that implies is that rather than the interface being "please write register X with value V", and then having platforms work-around that by reading various registers, we need a more flexible interface which passes the desired state. > > That's exactly what I meant when I talked on June 12th about turning > > cache-l2x0.c back into a pile of crap. You're working around problems > > rather than fixing the underlying issue, as seems to be standard > > platform maintainer behaviour when things like core ARM code is > > concerned. This is why things devolve over time into piles of crap, > > because platforms just hack around problems rather than fixing the > > root cause of the problem. > > I'm not sure what part of my patches exactly is turning cache-l2x0.c > into a pile of crap. On the contrary, I believe that working around the > firmware brokenness on platform level, while keeping the core code > simple does the opposite. What you're doing is making the future maintanence of cache-l2x0.c harder by breaking the modularity of it. By exposing the virtual address of the registers, reading the registers and getting your secure monitor to write them back, you're making assumptions about the behaviours inside cache-l2x0.c - while this may seem to be a no-op think about what happens a few years down the line when someone needs to change how this stuff operates, and you've long since moved on to new pastures and aren't around to answer questions on the exynos implementation. Compare that to modifying the implementation to give the secure monitors what they want - the desired state of the secure registers when enabling and resuming the L2 cache. The API becomes much clearer, and maintainable, because - from the core persective, there isn't a load of platforms doing weird crap with an API which doesn't really fit what they're trying to do. So, if we accept your patches as is and let that approach continue, then years down the line, cleaning up the crap that you've deposited becomes much harder, and we end up either having to break Exynos declaring it as a SoC we just don't give a damn about it, or keep the old interface. That is bad news which ever way you look at it. Quite simply, if a job is worth doing, then it's worth doing well and properly. The reason we have l2c_write_sec() right now is that when I sorted out the existing shitpile that platform maintainers had turned that code into over the years, it was the interface which suited the current implementations. As the secure APIs are typically confidential, there is no way to consider what other alternatives are out there, so this is something that is going to have to remain flexible - in other words, it needs to remain long term maintainable, so that it can change. So, working around it's short-comings in platform code is totally the wrong thing to do. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
(Ccing Guido back)
Hello Russell, Darren,
On 25 Jun 02:00 PM, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Martínez wrote:
> >> Use module_init instead of late_initcall, as is the norm for modular
> >> drivers.
> >>
> >> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> >> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> >> but it does not explain why. Tests show it's working properly with
> >> module_init.
> >>
> >
> > If I recall, the late_initcall stuff was done to try and make sure the
> > tda998x/i2c subsystem came up before tilcdc.
That doesn't make any sense. Using late_initcall for the tilcdc DRM
driver would make the tilcdc DRM get probed before any other regular
module_init driver, including the tda998x encoder.
> > However it didn't always
> > work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try
> > and ensure the ordering. This might be why changing back to module_init
> > is fine (and I agree with your assessment from my testing).
That commit is adds a proper probe deferal mechanism in case the
i2c is not available. OMAP is special because it has its own nasty initcall
to probe the i2c busses. However, that should be fixed and then i2c would be
always probed *after* the DRM, as per the ordering in drivers/Makefile.
>
> There's a solution to that...
A solution to *what* ?
> I have patches which convert the tda998x
> driver to also register into the component helpers as well as remaining
> as a drm slave device. This makes it possible to transition tilcdc to
> use the component helper to solve the initialisation ordering.
>
AFAIK, there's no issue with the initialisation ordering, except that the
DRM driver is currently probed before the TDA998x encoder and so the probe
is defered. Unless I'm missing something that's very easy to fix, you just
need to change the link order to guarantee that i2c encoders are probed
*before* the DRM drivers that require them.
I have just posted a very simple patch to fix it, but it seems Thierry wasn't
happy with it, not sure why yet [1].
[1] http://www.spinics.net/lists/dri-devel/msg61987.html
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
On 25.06.2014 15:50, Russell King - ARM Linux wrote: > On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: >> This series intends to add support for L2 cache on Exynos4 SoCs on boards >> running under secure firmware, which requires certain initialization steps >> to be done with help of firmware, as selected registers are writable only >> from secure mode. > > What I said in my message on June 12th applies to this series. I'm > not having the virtual address exposed via the write_sec call. > > Yes, you need to read other registers in order to use your secure > firmware implementation. Let's fix that by providing a better write_sec > interface so you don't have to read back these registers, rather than > working around this short-coming. Do you have anything in particular in mind? I would be glad to implement it and send patches. > > That's exactly what I meant when I talked on June 12th about turning > cache-l2x0.c back into a pile of crap. You're working around problems > rather than fixing the underlying issue, as seems to be standard > platform maintainer behaviour when things like core ARM code is > concerned. This is why things devolve over time into piles of crap, > because platforms just hack around problems rather than fixing the > root cause of the problem. I'm not sure what part of my patches exactly is turning cache-l2x0.c into a pile of crap. On the contrary, I believe that working around the firmware brokenness on platform level, while keeping the core code simple does the opposite. However, I'll be happy to rework my series if you have some more specific suggestions. > So... I'm NAKing the entire series. Your opinion is always appreciated, thanks. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: > This series intends to add support for L2 cache on Exynos4 SoCs on boards > running under secure firmware, which requires certain initialization steps > to be done with help of firmware, as selected registers are writable only > from secure mode. What I said in my message on June 12th applies to this series. I'm not having the virtual address exposed via the write_sec call. Yes, you need to read other registers in order to use your secure firmware implementation. Let's fix that by providing a better write_sec interface so you don't have to read back these registers, rather than working around this short-coming. That's exactly what I meant when I talked on June 12th about turning cache-l2x0.c back into a pile of crap. You're working around problems rather than fixing the underlying issue, as seems to be standard platform maintainer behaviour when things like core ARM code is concerned. This is why things devolve over time into piles of crap, because platforms just hack around problems rather than fixing the root cause of the problem. So... I'm NAKing the entire series. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback
For certain platforms (e.g. Exynos) it is necessary to read back some
values from registers before they can be written (i.e. SMC calls that
set multiple registers per call), so base address of L2C controller is
needed for .write_sec operation. This patch adds base argument to
.write_sec callback so that its implementation can also access registers
directly.
Signed-off-by: Tomasz Figa
---
arch/arm/include/asm/mach/arch.h | 3 ++-
arch/arm/include/asm/outercache.h | 2 +-
arch/arm/mach-highbank/highbank.c | 3 ++-
arch/arm/mach-omap2/omap4-common.c | 3 ++-
arch/arm/mach-ux500/cache-l2x0.c | 3 ++-
arch/arm/mm/cache-l2x0.c | 2 +-
6 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 060a75e..fefff4d 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -46,7 +46,8 @@ struct machine_desc {
enum reboot_modereboot_mode;/* default restart mode */
unsignedl2c_aux_val;/* L2 cache aux value */
unsignedl2c_aux_mask; /* L2 cache aux mask*/
- void(*l2c_write_sec)(unsigned long, unsigned);
+ void(*l2c_write_sec)(unsigned long,
+void __iomem *, unsigned);
struct smp_operations *smp; /* SMP operations */
bool(*smp_init)(void);
void(*fixup)(struct tag *, char **);
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b..25b70b5 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -35,7 +35,7 @@ struct outer_cache_fns {
void (*resume)(void);
/* This is an ARM L2C thing */
- void (*write_sec)(unsigned long, unsigned);
+ void (*write_sec)(unsigned long, void __iomem *, unsigned);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 8c35ae4..20cf160 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -51,7 +51,8 @@ static void __init highbank_scu_map_io(void)
}
-static void highbank_l2c310_write_sec(unsigned long val, unsigned reg)
+static void highbank_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
if (reg == L2X0_CTRL)
highbank_smc1(0x102, val);
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 326cd98..ce04afa 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -167,7 +167,8 @@ void __iomem *omap4_get_l2cache_base(void)
return l2cache_base;
}
-static void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
+static void omap4_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
unsigned smc_op;
diff --git a/arch/arm/mach-ux500/cache-l2x0.c b/arch/arm/mach-ux500/cache-l2x0.c
index 842ebed..bd87108 100644
--- a/arch/arm/mach-ux500/cache-l2x0.c
+++ b/arch/arm/mach-ux500/cache-l2x0.c
@@ -35,7 +35,8 @@ static int __init ux500_l2x0_unlock(void)
return 0;
}
-static void ux500_l2c310_write_sec(unsigned long val, unsigned reg)
+static void ux500_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
/*
* We can't write to secure registers as we are in non-secure
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index efc5cab..478566b 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -72,7 +72,7 @@ static void l2c_write_sec(unsigned long val, void __iomem
*base, unsigned reg)
if (val == readl_relaxed(base + reg))
return;
if (outer_cache.write_sec)
- outer_cache.write_sec(val, reg);
+ outer_cache.write_sec(val, base, reg);
else
writel_relaxed(val, base + reg);
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec callback is provided by this patch.
Signed-off-by: Tomasz Figa
---
arch/arm/mach-exynos/firmware.c | 63 +
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index eb91d23..def7bb4 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -14,7 +14,9 @@
#include
#include
+#include
#include
+#include
#include
@@ -70,6 +72,57 @@ static const struct firmware_ops exynos_firmware_ops = {
.cpu_boot = exynos_cpu_boot,
};
+static void exynos_l2_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
+{
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val & L2X0_CTRL_EN)
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_AUX_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP2,
+ readl_relaxed(base + L310_POWER_CTRL),
+ val, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ case L310_TAG_LATENCY_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ val,
+ readl_relaxed(base + L310_DATA_LATENCY_CTRL),
+ readl_relaxed(base + L310_PREFETCH_CTRL));
+ break;
+
+ case L310_DATA_LATENCY_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ readl_relaxed(base + L310_TAG_LATENCY_CTRL),
+ val,
+ readl_relaxed(base + L310_PREFETCH_CTRL));
+ break;
+
+ case L310_PREFETCH_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ readl_relaxed(base + L310_TAG_LATENCY_CTRL),
+ readl_relaxed(base + L310_DATA_LATENCY_CTRL),
+ val);
+ break;
+
+ case L310_POWER_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP2, val,
+ readl_relaxed(base + L2X0_AUX_CTRL), 0);
+ break;
+
+ default:
+ WARN_ONCE(1, "%s: ignoring write to reg 0x%x\n", __func__, reg);
+ }
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -89,4 +142,14 @@ void __init exynos_firmware_init(void)
pr_info("Running under secure firmware.\n");
register_firmware_ops(&exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+ && read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
+ outer_cache.write_sec = exynos_l2_write_sec;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] ARM: Get outer cache .write_sec callback from mach_desc only if not NULL
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 2c42576..e7383b9 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -125,7 +125,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_CACHE_L2X0) &&
(machine_desc->l2c_aux_mask || machine_desc->l2c_aux_val)) {
- outer_cache.write_sec = machine_desc->l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc->l2c_write_sec;
ret = l2x0_of_init(machine_desc->l2c_aux_val,
machine_desc->l2c_aux_mask);
if (ret)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] ARM: dts: exynos4: Add nodes for L2 cache controller
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..99970ab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -54,6 +54,15 @@
reg = <0x10023CA0 0x20>;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x10502000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ arm,tag-latency = <2 2 1>;
+ arm,data-latency = <2 2 1>;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x8000>;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943d..ddffefe 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -60,6 +60,20 @@
reg = <0x10023CA0 0x20>;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x10502000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ arm,tag-latency = <2 2 1>;
+ arm,data-latency = <3 2 1>;
+ arm,double-linefill = <1>;
+ arm,double-linefill-incr = <0>;
+ arm,double-linefill-wrap = <1>;
+ arm,prefetch-drop = <1>;
+ arm,prefetch-offset = <7>;
+ };
+
clock: clock-controller@1003 {
compatible = "samsung,exynos4412-clock";
reg = <0x1003 0x2>;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/6] ARM: mm: l2x0: Add support for overriding prefetch settings
Signed-off-by: Tomasz Figa
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
arch/arm/mm/cache-l2x0.c | 46 ++
2 files changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index b513cb8..8096fcd 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -44,6 +44,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 6600fd9..fd23cce 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1018,9 +1018,12 @@ static const struct l2c_init_data of_l2c220_data
__initconst = {
static void __init l2c310_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask)
{
+ bool set_prefetch = false;
u32 data[3] = { 0, 0, 0 };
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
+ u32 prefetch;
+ u32 val;
of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
if (tag[0] && tag[1] && tag[2])
@@ -1047,6 +1050,49 @@ static void __init l2c310_of_parse(const struct
device_node *np,
writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L310_ADDR_FILTER_EN,
l2x0_base + L310_ADDR_FILTER_START);
}
+
+ prefetch = readl_relaxed(l2x0_base + L310_PREFETCH_CTRL);
+
+ if (!of_property_read_u32(np, "arm,double-linefill", &val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch &= ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, "arm,double-linefill-incr", &val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch &= ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, "arm,double-linefill-wrap", &val)) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch &= ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, "arm,prefetch-drop", &val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch &= ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, "arm,prefetch-offset", &val)) {
+ prefetch &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val & L310_PREFETCH_CTRL_OFFSET_MASK;
+ set_prefetch = true;
+ }
+
+ if (set_prefetch)
+ l2c_write_sec(prefetch, l2x0_base, L310_PREFETCH_CTRL);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] ARM: mm: cache-l2x0: Use l2c_write_sec() for LATENCY_CTRL registers
According to the documentation, TAG_LATENCY_CTRL and DATA_LATENCY_CTRL registers of L2C-310 can be written only in secure mode, so l2c_write_sec() should be used to change them, instead of plain writel_relaxed(). Signed-off-by: Tomasz Figa --- arch/arm/mm/cache-l2x0.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 478566b..6600fd9 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -622,10 +622,10 @@ static void l2c310_resume(void) unsigned revision; /* restore pl310 setup */ - writel_relaxed(l2x0_saved_regs.tag_latency, - base + L310_TAG_LATENCY_CTRL); - writel_relaxed(l2x0_saved_regs.data_latency, - base + L310_DATA_LATENCY_CTRL); + l2c_write_sec(l2x0_saved_regs.tag_latency, + base, L310_TAG_LATENCY_CTRL); + l2c_write_sec(l2x0_saved_regs.data_latency, + base, L310_DATA_LATENCY_CTRL); writel_relaxed(l2x0_saved_regs.filter_end, base + L310_ADDR_FILTER_END); writel_relaxed(l2x0_saved_regs.filter_start, @@ -1024,20 +1024,20 @@ static void __init l2c310_of_parse(const struct device_node *np, of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag)); if (tag[0] && tag[1] && tag[2]) - writel_relaxed( + l2c_write_sec( L310_LATENCY_CTRL_RD(tag[0] - 1) | L310_LATENCY_CTRL_WR(tag[1] - 1) | L310_LATENCY_CTRL_SETUP(tag[2] - 1), - l2x0_base + L310_TAG_LATENCY_CTRL); + l2x0_base, L310_TAG_LATENCY_CTRL); of_property_read_u32_array(np, "arm,data-latency", data, ARRAY_SIZE(data)); if (data[0] && data[1] && data[2]) - writel_relaxed( + l2c_write_sec( L310_LATENCY_CTRL_RD(data[0] - 1) | L310_LATENCY_CTRL_WR(data[1] - 1) | L310_LATENCY_CTRL_SETUP(data[2] - 1), - l2x0_base + L310_DATA_LATENCY_CTRL); + l2x0_base, L310_DATA_LATENCY_CTRL); of_property_read_u32_array(np, "arm,filter-ranges", filter, ARRAY_SIZE(filter)); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/6] Enable L2 cache support on Exynos4210/4x12 SoCs
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
Patches 1-3 might affect other platforms using .write_sec callback, so
I'd like to kindly ask any interested people for testing.
Further two patches add impelmentation of .write_sec for Exynos secure
firmware and necessary DT nodes to enable L2 cache.
Tested on Exynos4210-based Universal C210 and Trats (both without secure
firmware) and Exynos4412-based TRATS2 and ODROID-U3 boards (both with secure
firmware).
Changes since v1:
(https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106323.html)
- rebased onto for-next branch of linux-samsung tree,
- changed argument order of outer_cache.write_sec() callback to match
l2c_write_sec() function in cache-l2x0.c,
- added support of overriding of prefetch settings to work around incorrect
default settings on certain Exynos4x12-based boards,
- added call to firmware to invalidate whole L2 cache before setting enable
bit in L2C control register (required by Exynos secure firmware).
Tomasz Figa (6):
ARM: mm: cache-l2x0: Add base address argument to write_sec callback
ARM: Get outer cache .write_sec callback from mach_desc only if not
NULL
ARM: mm: cache-l2x0: Use l2c_write_sec() for LATENCY_CTRL registers
ARM: mm: l2x0: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10
arch/arm/boot/dts/exynos4210.dtsi | 9
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/mach/arch.h | 3 +-
arch/arm/include/asm/outercache.h | 2 +-
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/firmware.c| 63 +
arch/arm/mach-highbank/highbank.c | 3 +-
arch/arm/mach-omap2/omap4-common.c | 3 +-
arch/arm/mach-ux500/cache-l2x0.c | 3 +-
arch/arm/mm/cache-l2x0.c | 64 ++
11 files changed, 162 insertions(+), 15 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 11:37:54AM +0100, Marc Zyngier wrote:
> All the Cortex-{A7,A15} implementations are using a GICv2. Same for
> the current arm64 platforms.
>
> Turns out that most of these platforms have described their GIC CPU
> interface size as being 4kB. while it is actually 8kB (the GICC_DIR
> register lives at offset 0x1000).
>
> This was found when converting the GIC driver to use EOImode==1 on
> GICv2-based systems. It uses the GICC_DIR register, and the result
> is a very early firework...
>
> Signed-off-by: Marc Zyngier
Just tested this on an Allwinner A31.
Acked-by: Maxime Ripard
Tested-by: Maxime Ripard
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
On Wed, Jun 25, 2014 at 02:00:42PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Martínez wrote:
> >> Use module_init instead of late_initcall, as is the norm for modular
> >> drivers.
> >>
> >> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> >> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> >> but it does not explain why. Tests show it's working properly with
> >> module_init.
> >>
> >
> > If I recall, the late_initcall stuff was done to try and make sure the
> > tda998x/i2c subsystem came up before tilcdc. However it didn't always
> > work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try
> > and ensure the ordering. This might be why changing back to module_init
> > is fine (and I agree with your assessment from my testing).
>
> There's a solution to that... I have patches which convert the tda998x
> driver to also register into the component helpers as well as remaining
> as a drm slave device. This makes it possible to transition tilcdc to
> use the component helper to solve the initialisation ordering.
>
> I'll (re-)post them later today.
Except Daniel Mack will not be receiving any copies of them:
zon...@gmail.com
SMTP error from remote mail server after end of data:
host gmail-smtp-in.l.google.com [2a00:1450:400c:c03::1a]:
550-5.7.1 [2001:4d48:ad52:3201:214:fdff:fe10:1be6 12] Our system has
550-5.7.1 detected that this message is likely unsolicited mail. To reduce
the
550-5.7.1 amount of spam sent to Gmail, this message has been blocked.
Please
550-5.7.1 visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131
for
550 5.7.1 more information. fs8si6627678wib.99 - gsmtp
Google's anti-ham filter seems to be working perfectly, allowing spam
through and blocking real messages... as usual. And as usual, google
provides no support for this crap. Gmail has a history of increasingly
blocking legitimate email in their alleged anti-spam fight. Don't use
gmail.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> On 06/17/2014 09:17 AM, Guido Martínez wrote:
>> Use module_init instead of late_initcall, as is the norm for modular
>> drivers.
>>
>> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
>> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
>> but it does not explain why. Tests show it's working properly with
>> module_init.
>>
>
> If I recall, the late_initcall stuff was done to try and make sure the
> tda998x/i2c subsystem came up before tilcdc. However it didn't always
> work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try
> and ensure the ordering. This might be why changing back to module_init
> is fine (and I agree with your assessment from my testing).
There's a solution to that... I have patches which convert the tda998x
driver to also register into the component helpers as well as remaining
as a drm slave device. This makes it possible to transition tilcdc to
use the component helper to solve the initialisation ordering.
I'll (re-)post them later today.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA7-evm: Enable SATA PHY and USB PHY power supplies
The SATA and USB PHYs need the 1.8V and 3.3V supplies.
The PHY drivers/framework don't yet support regulator
supply so we have to keep these regulators always-on till
then.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..99a1f79 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -241,6 +241,7 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
+ regulator-always-on;
};
ldo9_reg: ldo9 {
@@ -266,6 +267,7 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-boot-on;
+ regulator-always-on;
};
};
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25 2014 at 01:21:17 PM, Rob Herring wrote:
> On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier wrote:
>> All the Cortex-{A7,A15} implementations are using a GICv2. Same for
>> the current arm64 platforms.
>>
>> Turns out that most of these platforms have described their GIC CPU
>> interface size as being 4kB. while it is actually 8kB (the GICC_DIR
>> register lives at offset 0x1000).
>>
>> This was found when converting the GIC driver to use EOImode==1 on
>> GICv2-based systems. It uses the GICC_DIR register, and the result
>> is a very early firework...
>
> What's your plan for making the kernel change? Updating the dts files
> is good, but that doesn't immediately help you if you have old dtbs.
See at the end of https://lkml.org/lkml/2014/6/25/243
Basically, we stay with a GICv1 behaviour if we detect the mess.
>> Signed-off-by: Marc Zyngier
>> ---
>> arch/arm/boot/dts/axm55xx.dtsi | 2 +-
>> arch/arm/boot/dts/dra7.dtsi | 2 +-
>> arch/arm/boot/dts/ecx-2000.dts | 2 +-
>
> Acked-by: Rob Herring
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arch: arm: mach-omap2: usb-tusb6010.c: Cleaning up variable is set more than once
A struct member variable is set to the same value more than once This was found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- arch/arm/mach-omap2/usb-tusb6010.c |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index e832bc7..8333400 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -95,7 +95,6 @@ static int tusb_set_sync_mode(unsigned sysclk_ps) dev_t.t_avdp_w = t_scsnh_advnh; dev_t.cyc_aavdh_we = 3; dev_t.cyc_wpl = 6; - dev_t.t_ce_rdyz = 7000; gpmc_calc_timings(&t, &tusb_sync, &dev_t); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier wrote:
> All the Cortex-{A7,A15} implementations are using a GICv2. Same for
> the current arm64 platforms.
>
> Turns out that most of these platforms have described their GIC CPU
> interface size as being 4kB. while it is actually 8kB (the GICC_DIR
> register lives at offset 0x1000).
>
> This was found when converting the GIC driver to use EOImode==1 on
> GICv2-based systems. It uses the GICC_DIR register, and the result
> is a very early firework...
What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.
> Signed-off-by: Marc Zyngier
> ---
> arch/arm/boot/dts/axm55xx.dtsi | 2 +-
> arch/arm/boot/dts/dra7.dtsi | 2 +-
> arch/arm/boot/dts/ecx-2000.dts | 2 +-
Acked-by: Rob Herring
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
As this board use external clock for RMII interface we should specify 'rmii'
phy mode and 'rmii-clock-ext' to make ethernet working.
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 8a0a72d..a1a0cc5 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -105,10 +105,16 @@
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "rmii";
};
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
+ phy-mode = "rmii";
+};
+
+&phy_sel {
+ rmii-clock-ext;
};
&elm {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] drm/omap: Add infoframe & dvi/hdmi mode support
On 25/06/14 14:03, Archit Taneja wrote:
> Hi,
>
> On Tuesday 24 June 2014 03:34 PM, Tomi Valkeinen wrote:
>> Make the omapdrm driver use the new HDMI ops when possible.
>>
>> omapdrm will call set_hdmi_mode (when available) to tell the encoder
>> driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
>> monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
>> infoframe.
>
>
>
>
>> @@ -89,6 +91,31 @@ static void omap_encoder_mode_set(struct
>> drm_encoder *encoder,
>> struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode)
>> {
>> +struct drm_device *dev = encoder->dev;
>> +struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>> +struct omap_dss_device *dssdev = omap_encoder->dssdev;
>> +struct drm_connector *connector;
>> +bool hdmi_mode;
>> +int r;
>> +
>> +hdmi_mode = false;
>> +list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head) {
>> +if (connector->encoder == encoder) {
>> +hdmi_mode = omap_connector_get_hdmi_mode(connector);
>> +break;
>> +}
>> +}
>> +
>> +if (dssdev->driver->set_hdmi_mode)
>> +dssdev->driver->set_hdmi_mode(dssdev, hdmi_mode);
>
> When a HDMI monitor is replaced with a DVI one, we call the
> set_hdmi_mode() driver op to set the mode to DVI. But we don't call
> set_hdmi_infoframe() when the mode is set back to DVI. Do we need to set
> avi infoframe registers back to a default value, or are those registers
> just ignored in DVI mode?
If I'm not mistaken, infoframes are a HDMI thing. When in DVI mode, the
device driver should clear/disable/something the infoframe registers,
depending on the HW in question.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 1/2] arm: dts: am4372: let boards access all nodes through phandles
On Wed, Jun 25, 2014 at 02:40:16AM +0100, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jun 24, 2014 at 04:11:48PM -0500, Rob Herring wrote:
> > On Mon, Jun 23, 2014 at 1:20 PM, Felipe Balbi wrote:
> > > by providing phandles to rtc, wdt, cpu and dispc nodes,
> > > boards can access them to add board-specific data.
> >
> > Strictly speaking, you are adding labels, not phandles. You can do
>
> heh, fair point. Easily editable when applying, though (?)
>
> > phandles without using labels, but the syntax is not so obvious. I'd
> > tell you what it is but offhand I don't remember. :)
>
> something along the lines of using the full path ?
Yup. The full path in braces:
phandle-property = <&{/full/path/to/node@0xDEAD}>;
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 11:37:54AM +0100, Marc Zyngier wrote:
> All the Cortex-{A7,A15} implementations are using a GICv2. Same for
> the current arm64 platforms.
>
> Turns out that most of these platforms have described their GIC CPU
> interface size as being 4kB. while it is actually 8kB (the GICC_DIR
> register lives at offset 0x1000).
>
> This was found when converting the GIC driver to use EOImode==1 on
> GICv2-based systems. It uses the GICC_DIR register, and the result
> is a very early firework...
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm/boot/dts/axm55xx.dtsi | 2 +-
> arch/arm/boot/dts/dra7.dtsi | 2 +-
> arch/arm/boot/dts/ecx-2000.dts | 2 +-
> arch/arm/boot/dts/exynos3250.dtsi | 2 +-
> arch/arm/boot/dts/exynos5.dtsi | 2 +-
> arch/arm/boot/dts/exynos5260.dtsi | 2 +-
> arch/arm/boot/dts/exynos5410.dtsi | 2 +-
> arch/arm/boot/dts/exynos5440.dtsi | 2 +-
> arch/arm/boot/dts/omap5.dtsi| 2 +-
> arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
> arch/arm/boot/dts/r8a7790.dtsi | 2 +-
> arch/arm/boot/dts/r8a7791.dtsi | 2 +-
> arch/arm/boot/dts/sun6i-a31.dtsi| 2 +-
> arch/arm/boot/dts/sun7i-a20.dtsi| 2 +-
> arch/arm/boot/dts/tegra114.dtsi | 2 +-
> arch/arm/boot/dts/tegra124.dtsi | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
> arch/arm64/boot/dts/apm-storm.dtsi | 2 +-
> arch/arm64/boot/dts/foundation-v8.dts | 2 +-
> arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
> 21 files changed, 21 insertions(+), 21 deletions(-)
For the Tegra114 and Tegra124 patches:
Tested-by: Thierry Reding
Acked-by: Thierry Reding
pgpWE1cQD5evb.pgp
Description: PGP signature
Re: [PATCH 15/15] drm/omap: Add infoframe & dvi/hdmi mode support
Hi,
On Tuesday 24 June 2014 03:34 PM, Tomi Valkeinen wrote:
Make the omapdrm driver use the new HDMI ops when possible.
omapdrm will call set_hdmi_mode (when available) to tell the encoder
driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
infoframe.
@@ -89,6 +91,31 @@ static void omap_encoder_mode_set(struct drm_encoder
*encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct drm_device *dev = encoder->dev;
+ struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
+ struct omap_dss_device *dssdev = omap_encoder->dssdev;
+ struct drm_connector *connector;
+ bool hdmi_mode;
+ int r;
+
+ hdmi_mode = false;
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (connector->encoder == encoder) {
+ hdmi_mode = omap_connector_get_hdmi_mode(connector);
+ break;
+ }
+ }
+
+ if (dssdev->driver->set_hdmi_mode)
+ dssdev->driver->set_hdmi_mode(dssdev, hdmi_mode);
When a HDMI monitor is replaced with a DVI one, we call the
set_hdmi_mode() driver op to set the mode to DVI. But we don't call
set_hdmi_infoframe() when the mode is set back to DVI. Do we need to set
avi infoframe registers back to a default value, or are those registers
just ignored in DVI mode?
+
+ if (hdmi_mode && dssdev->driver->set_hdmi_infoframe) {
+ struct hdmi_avi_infoframe avi;
+
+ r = drm_hdmi_avi_infoframe_from_display_mode(&avi,
adjusted_mode);
+ if (r == 0)
+ dssdev->driver->set_hdmi_infoframe(dssdev, &avi);
+ }
}
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
Signed-off-by: Marc Zyngier
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5410.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi| 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi| 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi| 2 +-
arch/arm/boot/dts/tegra114.dtsi | 2 +-
arch/arm/boot/dts/tegra124.dtsi | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm64/boot/dts/apm-storm.dtsi | 2 +-
arch/arm64/boot/dts/foundation-v8.dts | 2 +-
arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index ea288f0..40aacc9 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -62,7 +62,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0x20 0x01001000 0 0x1000>,
- <0x20 0x01002000 0 0x1000>,
+ <0x20 0x01002000 0 0x2000>,
<0x20 0x01004000 0 0x2000>,
<0x20 0x01006000 0 0x2000>;
interrupts = ;
reg = <0x48211000 0x1000>,
- <0x48212000 0x1000>,
+ <0x48212000 0x2000>,
<0x48214000 0x2000>,
<0x48216000 0x2000>;
interrupts = ;
diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
index 2ccbb57f..c15e7e0 100644
--- a/arch/arm/boot/dts/ecx-2000.dts
+++ b/arch/arm/boot/dts/ecx-2000.dts
@@ -99,7 +99,7 @@
interrupt-controller;
interrupts = <1 9 0xf04>;
reg = <0xfff11000 0x1000>,
- <0xfff12000 0x1000>,
+ <0xfff12000 0x2000>,
<0xfff14000 0x2000>,
<0xfff16000 0x2000>;
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..bbd177a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -173,7 +173,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <1 9 0xf04>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..15fdc3b 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -44,7 +44,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <1 9 0xf04>;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 5398a60..c0e2341 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -161,7 +161,7 @@
#size-cells = <0>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <1 9 0xf04>;
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 3839c26..aa76aa5 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -76,7 +76,7 @@
#interr
Re: [PATCH 6/6] mailbox/omap: add a custom of_xlate function
On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller
> *controller,
> + const struct of_phandle_args *sp)
> +{
> + phandle phandle = sp->args[0];
> + struct device_node *node;
> + struct omap_mbox_device *mdev;
> + struct omap_mbox *mbox;
> +
> + node = of_find_node_by_phandle(phandle);
> + if (!node) {
> + pr_err("could not find node phandle 0x%x\n", phandle);
> + return NULL;
> + }
> +
> + mdev = container_of(controller, struct omap_mbox_device, controller);
> + if (WARN_ON(!mdev))
> + return NULL;
> +
> + mbox = omap_mbox_device_find(mdev, node->name);
> + return mbox ? mbox->chan : NULL;
>
Wouldn't it be easier to change the omap_mbox_device_find() function to
take a phandle argument directly? You shouldn't have to walk all
nodes in the system, or match it by name if you already have the
device node.
Also, the xlate function is normally the place where you read out
the other arguments and set them as members in your omap_mbox
structure.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
