errr ooops. highlighted too many lines. https://github.com/BeaglePilot/PRUSS-C/blob/master/PRUSS_LIB/AM335X_StarterWare_02_00_01_01/drivers/mcspi.c#L422-L469
On Thu, Dec 17, 2015 at 4:53 PM, William Hermans <[email protected]> wrote: > I'm not familiar with the McSPI hardware module, but this seems to explain > a good bit. And seems analogous( similar ) to how one would enable the ADC > module - Which is the only module I have hands on experience with by poking > it's registers . . e.g. turning the clock on, etc. > > > https://github.com/BeaglePilot/PRUSS-C/blob/master/PRUSS_LIB/AM335X_StarterWare_02_00_01_01/drivers/mcspi.c#L378-L469 > > On Thu, Dec 17, 2015 at 4:48 PM, William Hermans <[email protected]> > wrote: > >> I've no idea how ioremap() works, never used it. But if it's similar to >> how mmap() works on /dev/mem/, it does not matter what state the hardware >> module is in. Of course there are a few specified steps one must do in >> order to get a device working if it's not already. But if the device is >> already on, and functional, you can essentially override that module with >> mmap() and /dev/mem/. But it's probably not good idea, as the kernel will >> still think it has control . . . >> >> Anyway, I'm not sure I'd exactly call this a "driver" per se, as it's >> being done in userspace. But others might argue it's what's called a >> userspace driver . . . and yeah, I do not know about that. If you start >> changing pixels on your screen by poking at memory locations through >> /dev/mem/ does that mean you've created a graphics driver ? No . . . >> >> On Thu, Dec 17, 2015 at 4:08 PM, John Syne <[email protected]> wrote: >> >>> >>> On Dec 17, 2015, at 3:00 PM, William Hermans <[email protected]> wrote: >>> >>> *That is a good point. To understand how to enable the power and clock >>>> for McASP, look at the Starterware examples for McASP as they do everything >>>> you need to make this work.* >>>> >>> >>> Probably easier, and more productive to read the TRM for the AM335x >>> processors . . . All address offsets should be listed there as well, and >>> the introduction for hardware module will give a short explanation of what >>> needs doing, in order to bring the module up. >>> >>> Yeah, thinking about what Charles said, if he defines the McASP in the >>> device tree, it should setup everything he needs. One problem I’m not sure >>> how to overcome, he needs a device driver defined for the McASP or else the >>> clock and power won’t be setup. But if he has a device driver setup, then >>> it will conflict with his application. So that is why I think he has to do >>> all this manually. >>> >>> Regards, >>> John >>> >>> >>> On Thu, Dec 17, 2015 at 3:15 PM, John Syne <[email protected]> wrote: >>> >>>> >>>> >>>> > On Dec 17, 2015, at 1:59 PM, Charles Steinkuehler < >>>> [email protected]> wrote: >>>> > >>>> > On 12/17/2015 2:04 PM, [email protected] wrote: >>>> >> I am trying to access the McASP control registers. Reading from the >>>> first >>>> >> one fails with the kernel oops stating "external abort on >>>> non-linefetch >>>> >> (0x1028)". I dont know what that means. A minimum failing example of >>>> the >>>> >> code is below: >>>> > >>>> > <snip> >>>> > >>>> >> I have also tried request_mem_region around it, but that changes >>>> nothing. >>>> >> The sound drivers are not loaded, and the devicetree entry for the >>>> McASP is >>>> >> disabled, so there shouldn't be any problems with conflicts. >>>> > >>>> > One way to get this error is if the hardware you are talking to is >>>> > disabled. You need to either enable the hardware via the device tree, >>>> > or otherwise manage to setup the low-level SoC registers so the McASP >>>> > is provided a clock, power, and is taken out of reset. >>>> > >>>> > Most of the hardware blocks on the AM335x series can be individually >>>> > enabled or shut-down to save power. >>>> That is a good point. To understand how to enable the power and clock >>>> for McASP, look at the Starterware examples for McASP as they do everything >>>> you need to make this work. >>>> >>>> Regards, >>>> John >>>> > >>>> > -- >>>> > Charles Steinkuehler >>>> > [email protected] >>>> > >>>> > -- >>>> > 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 [email protected]. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
