[beagleboard] Accessing peripherals from the PRU

2015-04-23 Thread James Johnson
It's my understanding that you can access peripherals from the PRU. I can 
do this by reading/writing the appropriate addresses in the L4_PER memory 
map, correct?


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] BBB enable UART DMA 3.8 kernel?

2014-12-08 Thread James Johnson
Sorry if this is a dumb question, but how do I configure the AM335x's UARTs 
to use DMA mode under the 3.8 version of the kernel? Is it already 
configured to use DMA?

After Googling, the closest I can find is someone saying "use platform_data 
to enable DMA," but I'm sort of new to kernel hacking so I'm not sure how I 
would do that.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Disable DCAN automatic retransmission?

2014-11-01 Thread James Johnson
I'm trying to disable automatic retransmission on DCAN0 without much luck. 
I've tried flipping the bit in the control register manually using devmem2, 
and I've modified the driver so that it sets CONTROL_DISABLE_AR upon device 
initialization. So far I haven't had any luck. Does anyone have any ideas 
to share?

PS I know that automatic retransmission is part of the standard and is 
generally considered a Good Thing. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Re: AM335x RNG on BeagleBone (v3.8 Kernel)

2014-08-20 Thread James Johnson
Never mind, I figured it out. I haven't rigorously tested it yet but the 
/dev/hwrng node is populated and produces data as expected.

I'm attaching a patch if anyone's interested.

On Tuesday, August 19, 2014 12:46:47 PM UTC-5, James Johnson wrote:
>
>
> Hello BeagleBoard mailing list. Long time listener, first time caller.
>
> I've been trying to enable the AM335x onboard TRNG in the v3.8 kernel 
> without much success. I've built a kernel using the TI SDK source, which is 
> based on a v3.12 kernel, and the HWNRG works fine so I know it's not a 
> problem with the chip.
>
> Porting the driver over requires enabling support for the RNG's clock in 
> the 3.8 kernel. I've tried using the patches described here: 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195546.html 
> but these make the system hang on boot. It hangs too early for the kernel 
> to print error messages, so unfortunately I don't have any to provide.
>
> I have noticed that am33xx clock data is handled in device tree in v3.12, 
> while it's handled in hwmod in v3.8 (not sure if that's the correct way to 
> put it).
>
> Anyone have any ideas? I'm pretty new to kernel hacking with this 
> platform, and I'm still trying to grok the relationship between hwmod and 
> device tree.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 168dc7a..d5c1670 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -693,5 +693,12 @@
 			compatible = "ti,am335x-bandgap";
 			reg = <0x44e10448 0x8>;
 		};
+
+		rng: rng@48310 {
+		compatible = "ti,omap4-rng";
+			ti,hwmods = "rng";
+			reg = <0x4831 0x2000>;
+			interrupts = <111>;
+		};
 	};
 };
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index c028220..b761210 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -421,6 +421,10 @@ static struct clk aes0_fck;
 DEFINE_STRUCT_CLK_HW_OMAP(aes0_fck, NULL);
 DEFINE_STRUCT_CLK(aes0_fck, dpll_core_ck_parents, clk_ops_null);
 
+static struct clk rng_fck;
+DEFINE_STRUCT_CLK_HW_OMAP(rng_fck, NULL);
+DEFINE_STRUCT_CLK(rng_fck, dpll_core_ck_parents, clk_ops_null);
+
 /*
  * Modules clock nodes
  *
@@ -1151,6 +1155,7 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"smartreflex1_fck",	&smartreflex1_fck,	CK_AM33XX),
 	CLK(NULL,	"sha0_fck",		&sha0_fck,	CK_AM33XX),
 	CLK(NULL,	"aes0_fck",		&aes0_fck,	CK_AM33XX),
+CLK(NULL,   "rng_fck",  &rng_fck,   CK_AM33XX),
 	CLK(NULL,	"timer1_fck",		&timer1_fck,	CK_AM33XX),
 	CLK(NULL,	"timer2_fck",		&timer2_fck,	CK_AM33XX),
 	CLK(NULL,	"timer3_fck",		&timer3_fck,	CK_AM33XX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index a6d8070..8c05b95 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -471,8 +471,10 @@ static void omap_init_rng(void)
 	struct platform_device *pdev;
 
 	oh = omap_hwmod_lookup("rng");
-	if (!oh)
+	if (!oh){
+	  pr_err("Could not lookup rng hwmod\n");
 		return;
+	}
 
 	pdev = omap_device_build("omap_rng", -1, oh, NULL, 0, NULL, 0, 0);
 	WARN(IS_ERR(pdev), "Can't build omap_device for omap_rng\n");
@@ -631,9 +633,10 @@ static int __init omap2_init_devices(void)
 		omap_init_mcspi();
 		omap_init_sham();
 		omap_init_aes();
+		omap_init_rng();
 	}
 	omap_init_sti();
-	omap_init_rng();
+
 	omap_init_vout();
 	omap_init_ocp2scp();
 	if (soc_is_am33xx()) {
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 6e80edb..ee13d1e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -3452,6 +3452,52 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* rng */
+static struct omap_hwmod_class_sysconfig am33xx_rng_sysc = {
+  .rev_offs= 0x1fe0,
+  .sysc_offs= 0x1fe4,
+  .sysc_flags= SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE,
+  .idlemodes= SIDLE_FORCE | SIDLE_NO,
+  .sysc_fields= &omap_hwmod_sysc_type1,
+  };
+
+  static struct omap_hwmod_class am33xx_rng_hwmod_class = {
+  .name= "rng",
+  .sysc= &am33xx_rng_sysc,
+  };
+
+  static struct omap_hwmod am33xx_rng_hwmod = {
+  .name= "rng"

[beagleboard] AM335x RNG on BeagleBone (v3.8 Kernel)

2014-08-19 Thread James Johnson

Hello BeagleBoard mailing list. Long time listener, first time caller.

I've been trying to enable the AM335x onboard TRNG in the v3.8 kernel 
without much success. I've built a kernel using the TI SDK source, which is 
based on a v3.12 kernel, and the HWNRG works fine so I know it's not a 
problem with the chip.

Porting the driver over requires enabling support for the RNG's clock in 
the 3.8 kernel. I've tried using the patches described 
here: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195546.html 
but these make the system hang on boot. It hangs too early for the kernel 
to print error messages, so unfortunately I don't have any to provide.

I have noticed that am33xx clock data is handled in device tree in v3.12, 
while it's handled in hwmod in v3.8 (not sure if that's the correct way to 
put it).

Anyone have any ideas? I'm pretty new to kernel hacking with this platform, 
and I'm still trying to grok the relationship between hwmod and device tree.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.