Re: which "make" target simply builds the scripts/dtc/dtc executable?
Hi, Am 13.03.20 um 19:13 schrieb rpj...@crashcourse.ca: > colleague has a kernel-compile infrastructure which builds the > kernel just fine, but croaks trying to compile .dts files, complaining > that there is no "./scripts/dtc/dtc" file. > > ok, so that sounds like whatever it is that compiles dtc.c (and > friends) into dtc is being omitted. i just want to test whatever > make target would normally compile that, but i'm having trouble > figuring which make processing does that. > > is there a top-level target that wanders into scripts/dtc, and > compiles that? for a ARM target you could try to (PowerPC or MIPS should work too) export ARCH=arm make mxs_defconfig # random arm defconfig make dtbs this should build the devicetree compiler and the devicetree sources, but AFAIK newer kernel versions uses the dtc from the Host system. So it's possible that the dtc is omitted. Regards > > rday > > p.s. i'm testing this on x86, which typically doesn't use dtb files, > and there are no .dts files, so i'm looking for the target that > would normally compile into "dtc", even though there's nothing > that really needs it, if that makes a difference. > > i thought "make scripts_dtc" would do it, but that didn't seem to > make any difference. thoughts? > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Writing a Line discpline driver to talk to a stm32 controller
Hello Oliver, Am 23.03.2018 um 09:18 schrieb Oliver Graute: Hello list, I have a imx6ul connected to a stm32 controller via a serial interface. I need to implement a little protocol to talk towards the stm32 controller for send and receive ontop of the serial line. I found out that I have to write my own line discpline driver for doing this. After digging around in drivers/tty/n_* I have a little idea what to do here. I already attached my demo ldisc to a /dev/ttymxc7 via the ldattach command in userspace. This looks fine so far. Here my first Questions: Is there a way to permanent attach the ldisc to an serial interface in the Kernel? take a look at the serial device bus as an alternative for ldisc [1] Stefan [1] - https://elinux.org/images/0/0e/Serdev-elce-2017-2.pdf I have a reset GPIO to reset the stm32 controller. I would like to toggle this GPIO on opening the device. But the open() method in the ldisc driver seems the wrong place to do this. But in which open() should I do this? the underlying serial imx.c driver do not have any open() and I'am using this driver also for other serial lines? useful links to the ldisc topic: https://www.kernel.org/doc/Documentation/serial/tty.txt http://www.embeddedlinux.org.cn/essentiallinuxdevicedrivers/ Best Regards, Oliver ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Downgrade GSM/UMTS module to USB 2.0 Fullspeed
Hello Oliver, Am 18.01.2017 um 17:05 schrieb Oliver Graute: > Hello list, > > i'am using a GSM/UMTS Module on a PCB which is connected with USB 2.0 > Hi-Speed to my imx6ul CPU. To reduce our Electromagnetic compatibility > and to make my hardware colleges happy again I want to downgrade to USB > Full Speed. i think this topic fits better into the i.MX Community [1] Regards Stefan [1] - https://community.nxp.com/community/imx ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel thread naming convention
Hi, i want to improve the naming of some kernel threads from a staging driver. Here are the current (not really self explaining) names: "VCHIQ-%d" (slot handler) "VCHIQr-%d" (recycle thread) "VCHIQs-%d" (sync thread) "VCHIQka-%d" (keep alive thread) Is there any document which describe naming convention for kernel threads? Regards Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: PMU suspend/resume
Hi Amit, Am 01.11.2016 um 13:35 schrieb Amit Mahadik: > Hi, > I am trying to understand the Linux Power management Unit > framework. I have an ARM Cortex-A9x4 board. When I enable pm_test or > pass initcall_debug parameter through U-boot via bootargs the system > goes into (wfi/suspend state) and resumes properly. > However, the issue is when I disable pm_test and initcall_debug and put > my system into WFI/SUSPEND state , it does not resume even if the > registered wakeup IRQ is generated. > I am using linux kernel source revision 4.4.16. Can somebody please > help me regarding this issue? i have a similiar issue with a i.MX28 board [1]. Here are some question which should help to narrow down the issue: Are you able to reproduce the issue with current Mainline kernel 4.9rcX? What exact platform you are using? What are the exact commands to suspend your board? What device is your wakeup source? Does suspend already worked before? Did you try no_console_debug on a debug UART? Regards Stefan [1] - http://marc.info/?l=linux-arm-kernel&m=147721451006631&w=2 > > Regards, > Amit. > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are these books outdated?
Am 14.08.2016 um 21:48 schrieb Andrey Skvortsov: > On 11 Aug, Stefan Wahren wrote: >> Am 11.08.2016 um 05:52 schrieb Raul Piper: >>> Pdfdocs !! >>> Hmm that would be a nice Idea to collate all the Documentation of the >>> kernel into the pdfs and make a book out of it for any kernel version >>> we want ! >>> Thanks ! >> >> There is a german book [1] which handles Kernel 4.x and device trees. >> But i don't know if any translation is planned. > > Thank you for the link and information about book. > Unfortunately after your message, public access to the book was > removed on the site. > It's pity that I've not downloaded Latex source > code of the last edition, when they were available. That's strange. I provided the link because of the 4nd edition of the book. The online version was about the 3rd edition which handled Kernel 2.6. > >> [1] - https://ezs.kr.hsnr.de/TreiberBuch/ > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are these books outdated?
Am 11.08.2016 um 05:52 schrieb Raul Piper: > Pdfdocs !! > Hmm that would be a nice Idea to collate all the Documentation of the > kernel into the pdfs and make a book out of it for any kernel version > we want ! > Thanks ! There is a german book [1] which handles Kernel 4.x and device trees. But i don't know if any translation is planned. [1] - https://ezs.kr.hsnr.de/TreiberBuch/ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pushing other commits upstream
Hi, Am 18.07.2016 um 00:49 schrieb Alexander Couzens: > Hi, > > I would like to push patches from somebody else upstream. > I'm talking of commits of the TI's beagleboard repo [1]. > > What do I need to take care of? try to contact the author of those patches and ask if they can go upstream. Sometimes downstream patches are hacky and not intended for mainline. Stefan > > Best, > lynxis > > [1] https://github.com/beagleboard/linux > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: strange dtc errors after adding sram node
Hi Arnd, Am 25.04.2016 um 15:06 schrieb Arnd Bergmann: > On Monday 25 April 2016 08:04:53 Stefan Wahren wrote: >> >> i've found reason for these errors. I missed to adjust the affected dts >> files which refer to the ahb node. > > Makes sense. Maybe you can just remove the address and 'reg' property from > the ahb node? is this a proposal for a patch set? Does it apply to all top-level nodes like apb? > That should solve the dtc problem and make the contents > more like what we have elsewhere. Does it refer to a specific patch / discussion or something? Regards Stefan > > Arnd > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: strange dtc errors after adding sram node
Hi Jörg,
Am 23.04.2016 um 12:33 schrieb Jörg Krause:
> Hi Stefan,
>
> On Sa, 2016-04-23 at 10:18 +0200, Jörg Krause wrote:
>> Hi Stefan,
>>
>> On Sa, 2016-04-23 at 09:46 +0200, Stefan Wahren wrote:
>>> Hi,
>>>
>>> i want to add an sram node to arch/arm/boot/dts/imx28.dtsi.
>>> According
>>> to
>>> the reference manual [1] the On-Chip RAM is connected to AHB,
>>> start
>>> address 0 and has a size of 128 KB.
>>>
>>> So i modified the imx28.dtsi based on the patch below.
>>> Unfortunately
>>> the
>>> dtc give me some strang errors:
>>>
>>> ERROR (duplicate_label): Duplicate label 'mac0' on
>>> /ahb@8008/ethernet@800f and /ahb@/ethernet@800f
>>> ERROR: Input tree has errors, aborting (use -f to force output)
>>>
>>> What's wrong with my patch or does it reveal another issue?
>>>
>>> Regards
>>> Stefan
>>>
>>> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM
>>> .p
>>> df
>>> i.MX28 Applications Processor Reference Manual, Rev. 2, 08/2013
>>> Chapter 4.1 Memory Map Overview
>>>
>>> -->8---
>>> --- a/arch/arm/boot/dts/imx28.dtsi
>>> +++ b/arch/arm/boot/dts/imx28.dtsi
>>> @@ -1311,13 +1311,18 @@
>>> };
>>> };
>>>
>>> - ahb@8008 {
>>> + ahb@ {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - reg = <0x8008 0x8>;
>>> + reg = <0x 0x2>, <0x8008 0x8>;
>>> ranges;
>>>
>>> + ocram: sram@ {
>>> + compatible = "mmio-sram";
>>> + reg = <0x 0x2>;
>>> + };
>>> +
>>> usb0: usb@8008 {
>>> compatible = "fsl,imx28-usb", "fsl,imx27-
>>> usb";
>>> reg = <0x8008 0x1>;
>>
>> Follwing the address map for the i.MX28 (p. 125ff) the AHB is mapped
>> to
>> different start addresses:
>>
>> Bus MNEMONICSTART ADDRESS
>> --
>> AHB OCRAM 0x
>> AHB USBCTRL00x8008
>> AHB OCROM 0xC000
>>
>> So instead of replacing ahb@8008 by ahb@ a new node
>> should
>> be created. However, I am not sure if this is really necessary, I
>> haven't seen it for all device trees using "mmio-sram".
>
> Sorry, for not looking carefully enough at your patch. Haven't seen you
> adjusted the 'reg' property. I tried with an additional ahb@ no
> de and this did work.
>
> So, there is really something odd here...
i've found reason for these errors. I missed to adjust the affected dts
files which refer to the ahb node.
Stefan
>
> Best regards
> Jörg Krause
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
strange dtc errors after adding sram node
Hi,
i want to add an sram node to arch/arm/boot/dts/imx28.dtsi. According to
the reference manual [1] the On-Chip RAM is connected to AHB, start
address 0 and has a size of 128 KB.
So i modified the imx28.dtsi based on the patch below. Unfortunately the
dtc give me some strang errors:
ERROR (duplicate_label): Duplicate label 'mac0' on
/ahb@8008/ethernet@800f and /ahb@/ethernet@800f
ERROR: Input tree has errors, aborting (use -f to force output)
What's wrong with my patch or does it reveal another issue?
Regards
Stefan
[1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
i.MX28 Applications Processor Reference Manual, Rev. 2, 08/2013
Chapter 4.1 Memory Map Overview
-->8---
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1311,13 +1311,18 @@
};
};
- ahb@8008 {
+ ahb@ {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x8008 0x8>;
+ reg = <0x 0x2>, <0x8008 0x8>;
ranges;
+ ocram: sram@ {
+ compatible = "mmio-sram";
+ reg = <0x 0x2>;
+ };
+
usb0: usb@8008 {
compatible = "fsl,imx28-usb", "fsl,imx27-usb";
reg = <0x8008 0x1>;
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about DC-DC frequency handling
Hi, > Michael Turquette hat am 26. April 2015 um 21:07 > geschrieben: > > > Quoting Stefan Wahren (2015-04-26 07:31:30) > > Hi, > > > > i'm current working on a regulator driver which should be able to change > > DC-DC > > clock frequency. > > > > Now here is my question. What is the prefered way to implement the clock > > handling? > > Fun question. I have a question for you: who are the consumers of this > DC-DC? Do the downstream, consuming devices care about "clock rate" of > your regulator? > > I'll hazard a guess that they do not care. DC-DC switching frequency is > an important aspect of power supply design, but switching frequency of a > power supply is not controlled by the clock framework in any example > that I am aware of. yes the consumers don't care. My intension for changing the switching frequency is to avoid interferences on HF band. > > > > > Option A): > > > > The regulator driver handles all internally (select clock source, set > > frequency). > > Mark should weigh in on this, but I think option A is correct. Maybe > something like regulator_set_mode could program your switching > frequency? A runtime configuration isn't necessary. In a earlier discussion we decided to use a devicetree property. Thanks Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question about DC-DC frequency handling
Hi, i'm current working on a regulator driver which should be able to change DC-DC clock frequency. Now here is my question. What is the prefered way to implement the clock handling? Option A): The regulator driver handles all internally (select clock source, set frequency). Option B): The DC-DC clock domain is implemented in the clock driver and the regulator driver uses the clock framework. Best regards Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about shared interrupts in devicetree
> Mark Rutland hat am 7. April 2015 um 13:29 geschrieben: > > > On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote: > > Hi, > > Hi, > > > i'm currently working on drivers (regulator and power switch) for a power > > subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for > > the > > power subsystem which share the same interrupt line. This interrupt line is > > needed by both drivers (regulator and power switch). > > > > Now the question what is the right way (tm) to specify the interrupt in the > > devicetree and fetch the irq number during driver probe? > > If the interrupts are generated by the subsystem as a whole, then A > would be more correct. If you can read some shared register to determine > the particular sub-block which generated the interrupt, A would > certainly be the right way of describing the HW. Just for the records. I asked this question in the Freescale Community and a Freescale employee reported that the interrupts are generated by the subsystem as a whole and there is no logical grouping. Thanks Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about shared interrupts in devicetree
Hi Geert,
> Geert Uytterhoeven hat am 9. April 2015 um 09:37
> geschrieben:
>
> [...]
>
> >
> > Could you please explain the benefit / reason of this approach?
>
> Since you have different logical modules in the subsystem, this allows to
> model
> the subsystem as separate modules and a separate interrupt controller, and
> have separate drivers for all modules.
>
> Look at da9063 for an example (there are more according to "git grep irq_chip
> -- drivers/mfd", but not all of them may have DT bindings).
>
thanks for the hint, but this makes my patch series not really smaller. I
invested a lot of time (started in September 2014) and i want to submit at least
1 of the 3 drivers soon as possible.
I think the best approch would be to submit my series with option B as a
proposal. In the discussion about the patch it would be easier to decide if a
interrupt controller is really necessary.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Stefan
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about shared interrupts in devicetree
Hi Geert,
Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven:
> On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren wrote:
>> [...]
>>
>> thanks for the good explanation. After looking into the reference manual [1]
>> of
>> the i.MX28 i still can't decide if the subsystem generate the interrupts as a
>> whole or
>> as a logical group. I only found this para in chapter 11.11:
>>
>> The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each
>> have their own interrupt line back to the interrupt collector.
>> However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ,
>> VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single
>> interrupt line. In this case, software must read the interrupt status
>> bits to discover which event caused the interrupt.
>>
>> In my case DC_OK_IRQ and PSWITCH_IRQ are relevant.
>>
>> Maybe someone else has a idea?
> Perhaps you can implement an interrupt-controller to handle the multiplexing
> of the 5 remaining interrupts?
Could you please explain the benefit / reason of this approach?
>
> Can they be disabled/enabled individually?
Yes. What are the consequences?
Thanks Stefan
>
>> Thanks Stefan
>>
>> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
>>
>> Document Number: MCIMX28RM
>> Rev 2, 08/2013
>>
>>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about shared interrupts in devicetree
Hi Mark,
[add some possible interested developer in CC]
> Mark Rutland hat am 7. April 2015 um 13:29 geschrieben:
>
>
> On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote:
> > Hi,
>
> Hi,
>
> > i'm currently working on drivers (regulator and power switch) for a power
> > subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for
> > the
> > power subsystem which share the same interrupt line. This interrupt line is
> > needed by both drivers (regulator and power switch).
> >
> > Now the question what is the right way (tm) to specify the interrupt in the
> > devicetree and fetch the irq number during driver probe?
>
> If the interrupts are generated by the subsystem as a whole, then A
> would be more correct. If you can read some shared register to determine
> the particular sub-block which generated the interrupt, A would
> certainly be the right way of describing the HW.
>
> If the subsystem is just a logical grouping, and the two units generate
> separate interrupts which simply get muxed together (with nothing
> special done at the subsystem level), then B would seem more correct, as
> the two units are effectively independent.
>
> It really depends on way the HW is organised, and how the HW _could_ be
> organised if reused, so this is a grey area generally.
>
> It looks like it would be possible to support both styles if we need to
> (by checking the node first, then its parent), if we go for one option
> and later discover we need the other.
thanks for the good explanation. After looking into the reference manual [1] of
the i.MX28 i still can't decide if the subsystem generate the interrupts as a
whole or
as a logical group. I only found this para in chapter 11.11:
The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each
have their own interrupt line back to the interrupt collector.
However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ,
VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single
interrupt line. In this case, software must read the interrupt status
bits to discover which event caused the interrupt.
In my case DC_OK_IRQ and PSWITCH_IRQ are relevant.
Maybe someone else has a idea?
Thanks Stefan
[1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
Document Number: MCIMX28RM
Rev 2, 08/2013
>
> Thanks,
> Mark.
>
> >
> > Option A (define interrupt in parent node):
> >
> > power: power@80044000 {
> > compatible = "fsl,imx28-power", "syscon";
> > reg = <0x80044000 0x2000>;
> > interrupts = <6>;
> >
> > reg_vddd: regulator@1 {
> > compatible = "fsl,imx28-vddd";
> > };
> >
> > pswitch: pswitch@5 {
> > compatible = "fsl,mxs-pswitch";
> > linux,code = <116>;
> > };
> > }
> >
> > int irq = irq_of_parse_and_map(parent, 0);
> >
> > Option B (define interrupt for each child node):
> >
> > power: power@80044000 {
> > compatible = "fsl,imx28-power", "syscon";
> > reg = <0x80044000 0x2000>;
> >
> > reg_vddd: regulator@1 {
> > compatible = "fsl,imx28-vddd";
> > interrupts = <6>;
> > };
> >
> > pswitch: pswitch@5 {
> > compatible = "fsl,mxs-pswitch";
> > linux,code = <116>;
> > interrupts = <6>;
> > };
> > }
> >
> > int irq = platform_get_irq(pdev, 0);
> >
> > Best regards
> > Stefan
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question about shared interrupts in devicetree
Hi,
i'm currently working on drivers (regulator and power switch) for a power
subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for the
power subsystem which share the same interrupt line. This interrupt line is
needed by both drivers (regulator and power switch).
Now the question what is the right way (tm) to specify the interrupt in the
devicetree and fetch the irq number during driver probe?
Option A (define interrupt in parent node):
power: power@80044000 {
compatible = "fsl,imx28-power", "syscon";
reg = <0x80044000 0x2000>;
interrupts = <6>;
reg_vddd: regulator@1 {
compatible = "fsl,imx28-vddd";
};
pswitch: pswitch@5 {
compatible = "fsl,mxs-pswitch";
linux,code = <116>;
};
}
int irq = irq_of_parse_and_map(parent, 0);
Option B (define interrupt for each child node):
power: power@80044000 {
compatible = "fsl,imx28-power", "syscon";
reg = <0x80044000 0x2000>;
reg_vddd: regulator@1 {
compatible = "fsl,imx28-vddd";
interrupts = <6>;
};
pswitch: pswitch@5 {
compatible = "fsl,mxs-pswitch";
linux,code = <116>;
interrupts = <6>;
};
}
int irq = platform_get_irq(pdev, 0);
Best regards
Stefan
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Overlapping regions in DT
Hi Tsahee, Am 09.02.2015 um 09:22 schrieb Tsahee Zidenberg: > syscon regmap is one possible way to access a register file from two > different drivers without mapping it twice. But in that case you loose > the name-per-register in devicetree. The devtree maps the general > regfile, and the drivers know the offsets by themselves. > Have a look here: > Have a look: http://thread.gmane.org/gmane.linux.kernel/1352299 thanks for your suggestion. I'll give it a try. Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Overlapping regions in DT
Hi,
currently i work on two DT capable drivers for a ARM9 processor. The former
driver mxs_power.c should trigger the population of the underlying power
management functions and the ladder take care of the on-chip regulators. In the
future more drivers
should be added as child nodes of the power driver.
My problem is that some of the processor registers are not separated per
function. So
the drivers need access (mostly read) on the same registers.
Here are my questions:
How should define i the register space in the device?
Define the regions in the parent node and use offsets in the childs?
Which functions are recommend for such access?
I want to make use of of_platform_populate / of_platform_depopulate.
Is there anything i should take care of?
The relevant parts of the devicetree is at the end of the mail.
Best regards
Stefan
power: power@80044000 {
compatible = "fsl,imx28-power"; /* handled by mxs_power.c */
#address-cells = <1>;
#size-cells = <1>;
reg = <0x80044000 0x2000>;
interrupts = <6>;
ranges;
reg_vddd: regulator@80044040 {
reg = <0x80044040 0x10>,
<0x80044010 0x10>,
<0x800440c0 0x10>;
reg-names = "base-address",
"v5ctrl-address",
"status-address";
compatible = "fsl,imx28-vddd"; /* handled by
mxs-regulator.c */
regulator-name = "vddd";
regulator-min-microvolt = <135>;
regulator-max-microvolt = <155>;
vddd-supply = <®_vdda>;
};
reg_vdda: regulator@80044050 {
reg = <0x80044050 0x10>,
<0x80044010 0x10>,
<0x800440c0 0x10>;
reg-names = "base-address",
"v5ctrl-address",
"status-address";
compatible = "fsl,imx28-vdda"; /* handled by
mxs-regulator.c */
regulator-name = "vdda";
regulator-min-microvolt = <1725000>;
regulator-max-microvolt = <195>;
vdda-supply = <®_vddio>;
};
reg_vddio: regulator@80044060 {
reg = <0x80044060 0x10>,
<0x80044010 0x10>,
<0x800440c0 0x10>;
reg-names = "base-address",
"v5ctrl-address",
"status-address";
compatible = "fsl,imx28-vddio"; /* handled by
mxs-regulator.c */
regulator-name = "vddio";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <3575000>;
regulator-microvolt-offset = <8>;
};
};
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Subsystem communication
Am 13.10.2014 um 22:45 schrieb Stefan Wahren: > Hi, > > currently i want to implement a driver for the power subsystem of the > Freescale > i.MX28 (ARM9). On the one hand the driver should trigger the registering of > the > underlying components like regulators and on the other hand it should take > care > of the incoming interrupts and provide the results to the underlying > components. > > I think the first task can easily done by of_platform_populate(). > > But for the second task i'm not sure how to achieve a clean, mostly readonly > access from the regulator drivers to the power subsystem driver. > > I have read about exporting symbols and RCU, but i'm not sure what's preferred > in that situation. > > Best regards > > Stefan > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ping ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Subsystem communication
Hi, currently i want to implement a driver for the power subsystem of the Freescale i.MX28 (ARM9). On the one hand the driver should trigger the registering of the underlying components like regulators and on the other hand it should take care of the incoming interrupts and provide the results to the underlying components. I think the first task can easily done by of_platform_populate(). But for the second task i'm not sure how to achieve a clean, mostly readonly access from the regulator drivers to the power subsystem driver. I have read about exporting symbols and RCU, but i'm not sure what's preferred in that situation. Best regards Stefan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
