On Thu, 12 Sep 2013 17:57:00 +0200, Alexander Holler
wrote:
> Am 12.09.2013 17:19, schrieb Stephen Warren:
> >
> > IRQs, DMA channels, and GPIOs are all different things. Their bindings
> > are defined independently. While it's good to define new types of
> > bindings consistently with other bind
On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár
* Luca Coelho [130916 23:35]:
> On Tue, 2013-09-17 at 09:26 +0300, Luca Coelho wrote:
> > Both patches look good to me, though I didn't have the time to retest
> > them.
>
> Actually I don't even have a Blaze device anymore, so I can't really
> test the second patch. :(
OK no problem, I've teste
* Aaro Koskinen [130907 16:10]:
> Hi,
>
> On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c
> [...]
> > Ping, can you review this patch v2?
>
> I don't think Tony will accept any new board stuff for RX-51/N900.
> S
* Kevin Hilman [130827 09:01]:
> Vladimir Murzin writes:
>
> > We call cpu_cluster_pm_enter for dev->cpu == 0 only, but
> > cpu_cluster_pm_exit called without that check.
> >
> > Because of that unhandled page fault may happen:
> >
> > [3.803405] Unable to handle kernel paging request at vir
* Suman Anna [130823 09:50]:
> + OMAP mailing list
>
> Tony,
> Can you pick up this minor cleanup patch?
>
> regards
> Suman
>
> On 08/21/2013 09:10 PM, Jingoo Han wrote:
> > The driver core clears the driver data to NULL after device_release
> > or on probe failure. Thus, it is not needed to m
* Josh Boyer [130904 06:46]:
> The board-omap3evm.c file unconditionally calls usb_nop_xceiv_register but
> doesn't ensure this is built-in. This can lead to build failures like:
>
> arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
> linux-3.12.0-0.rc0.git2.1.fc21.armv7hl/arch/arm/m
* Kevin Hilman [130826 17:17]:
> Tony Lindgren writes:
>
> > Kevin,
> >
> > * Wei Yongjun [130704 06:48]:
> >> From: Wei Yongjun
> >>
> >> In case of error, the function omap_device_alloc() returns ERR_PTR()
> >> and never returns NULL. The NULL test in the return value check
> >> should be r
* Pali Rohár [130710 06:06]:
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
This file will be gone as soon as we're moving to device
tree based booting. So let's do this in more future proof
way.
> +/**
> + * rx51_secure_dispatcher: Routine to dispatch secure P
* Pali Rohár [130917 09:01]:
> On Tuesday 17 September 2013 17:43:31 Tony Lindgren wrote:
> > Have you guys checked how this works with the recently posted
> > "[PATCH v6 0/5] ARM: support for Trusted Foundations secure
> > monitor" series?
>
> this code looks like some Tegra and "Trusted Foundat
Hi Linus,
On Tuesday 17 September 2013 14:51:48 Linus Walleij wrote:
> On Wed, Sep 4, 2013 at 9:03 AM, George Cherian wrote:
> > This patch series
> >
> > - removes the irq_demux_work
> > - Uses devm_request_threaded_irq
> > - Call the user handler iff gpio_to_irq is done.
Hi Benoit,
> On 08/08/2013 17:44, Suman Anna wrote:
>> On 08/08/2013 09:34 AM, Kumar Gala wrote:
>>>
>>> On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
>>>
On 08/07/2013 12:41 PM, Kumar Gala wrote:
>
> On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
>
>> Kumar,
>>
L
Hi,
My question is related to the drivers/mmc/host/omap_hsmmc.c host
controller compatibility with SDXC for the OMAP35x?
Reading the TRM for OMAP35x:
http://www.ti.com/lit/ug/spruf98x/spruf98x.pdf
It's said that:
- Full compliance with SD command/response sets as defined in the SD
Memory Card Sp
Add the hwmod data for the spinlock IP in OMAP5 SoC.
This is needed to be able to enable the OMAP spinlock
support for OMAP5.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/mach
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna
---
.../devicetree/bindings/hwlo
Add the hwspinlock device tree node for AM33xx family
of SoCs.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4371257 100644
--- a/arch/arm/boot/dts
Add the hwspinlock device tree node for OMAP5 SoCs.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..449be92 100644
--- a/arch/arm/boot/dts/omap5.dtsi
++
On Tue, Sep 17, 2013 at 3:02 AM, Tomi Valkeinen wrote:
> On 17/09/13 12:38, Mike Turquette wrote:
>> Quoting Archit Taneja (2013-09-17 00:06:28)
>>> HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
>>> existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file
Add the missing sysc configuration to the AM335 spinlock hwmod
data. This ensures that smart-idle is enabled whenever the module
is enabled by the driver.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/a
Add the hwspinlock device tree node for OMAP4 family
of SoCs.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a8cc274 100644
--- a/arch/arm/boot/dts/oma
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled
AM33XX device family also supports hwspinlocks. The IP
is identical to that of OMAP4/OMAP5, except for the
number of locks.
Signed-off-by: Suman Anna
---
drivers/hwspinlock/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation
Hi,
This is an updated series for adding the device tree support to
the OMAP hwspinlock driver. The series is based on 3.12-rc1, and
includes patches on hwspinlock driver, OMAP hwmod data files and
OMAP DTS files. The updated series adds new patches to enable the
hwspinlock driver on OMAP5 and AM3
On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > More power supply drivers depends on vbus events and
Hi,
has anyone ever successfully using gpio-pcf857x.c driver with 16-bit
gpio expanders ? We're having some issues here where toggling the last
gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I
can't come up with any explanation of why would it hang...
Any hints ?
cheers
--
On Tuesday 17 September 2013 12:47 PM, Nishanth Menon wrote:
> CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
> same. Without a valid value arch_timer_init results in div0 crash.
s/same/timer frequency via DT
> Providing the same is a safer alternative.
Above statement won't be n
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
timer frequency via DT. Without a valid value arch_timer_init results
in div0 crash.
Cc: R Sricharan
Cc: Rajendra Nayak
Cc: Sourav Poddar
Acked-by: Santosh Shilimkar
Signed-off-by: Nishanth Menon
---
Based on Benoit's for_3.1
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
same. Without a valid value arch_timer_init results in div0 crash.
Providing the same is a safer alternative.
Cc: R Sricharan
Cc: Rajendra Nayak
Cc: Sourav Poddar
Cc: Santosh Shilimkar
Signed-off-by: Nishanth Menon
---
Based
* Tomi Valkeinen [130829 06:40]:
> The DPI and SDI platform devices are currently created with the ID of
> -1. The ID doesn't currently affect anything.
>
> However, we have added regulator supply entries for "omapdss_dpi.0" and
> "omapdss_sdi.0" to the board files, although these supply entries
On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> >
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
>
> So without atomic notifier
On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
> > On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi Greg,
> >>
> >> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> >>> Hi,
> >
On Tuesday 17 September 2013 17:43:31 Tony Lindgren wrote:
> * Dave Martin [130916 10:18]:
> > On Sat, Sep 14, 2013 at 10:37:12AM +0100, Pali Rohár wrote:
> > > On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
> > > > + */
> > > > +ENTRY(omap_smc3)
> > > > + stmfd sp!, {r4-r11, lr}
>
* Dave Martin [130916 10:18]:
> On Sat, Sep 14, 2013 at 10:37:12AM +0100, Pali Rohár wrote:
> > On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
> > > + */
> > > +ENTRY(omap_smc3)
> > > + stmfd sp!, {r4-r11, lr}
> > > + mov r12, r0 @ Copy the secure service ID
> > > + mov r
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int tw
Hi,
On Thu, Sep 12, 2013 at 04:17:08PM +0530, Vivek Gautam wrote:
> On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros wrote:
> > Hi Kishon,
> >
> > On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
> >> There can be systems which does not have a external usb_phy, so get
> >> usb_phy only if usb-
* Tero Kristo [130829 06:24]:
> The OMAP clock driver now supports DPLL clock type. This patch also
> adds support for DT DPLL nodes.
...
> +- reg-names : array of the register names for controlling the device, sorted
> + in the same order as the reg property.
> + "control" - contains the co
On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > cal
On 09/17/2013 09:31 AM, Afzal Mohammed wrote:
> Hi Nishant,
>
> On Monday 16 September 2013 08:56 PM, Nishanth Menon wrote:
>> On 09/16/2013 08:48 AM, Afzal Mohammed wrote:
>
>>> From: Ambresh K
>>>
>>> Add the data file to describe clock domains in AM43x SoC.
>>> OMAP4 clockdomain operations is
On 09/17/2013 01:05 AM, Sekhar Nori wrote:
[..]
>>> mixed messages. In short, we aim for consistency with situation today,
>>> not tomorrow.
>>
>> What you're asking to do infact breaks consistency with the rest of the code.
>
> Well, ideally we support second CC even with DT to be consistent all
Hi Nishant,
On Monday 16 September 2013 08:56 PM, Nishanth Menon wrote:
> On 09/16/2013 08:48 AM, Afzal Mohammed wrote:
>> From: Ambresh K
>>
>> Add the data file to describe clock domains in AM43x SoC.
>> OMAP4 clockdomain operations is being reused here.
>>
>> Signed-off-by: Ambresh K
>> Sign
On Tue, Sep 17, 2013 at 2:43 PM, Russ Dill wrote:
> +++ b/arch/alpha/include/asm/fncpy.h
> @@ -0,0 +1 @@
> +#include
Please add
generic-y += fncpy.h
to arch//include/asm/Kbuild instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyon
CONFIDENTIAL TRUST REPLY .
Dear Friend,
I am contacting you to assist me in the transfer of $6,200,000.00 into your
personal bank account for our benefit, this transaction is confidential and we
MUST remain fiducially in all our dealings since I cannot execute this
o
Hi Suman,
On 08/08/2013 17:44, Suman Anna wrote:
On 08/08/2013 09:34 AM, Kumar Gala wrote:
On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
On 08/07/2013 12:41 PM, Kumar Gala wrote:
On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
Kumar,
Logic has been added to the OMAP2+ mailbox code to
pa
Hi Koen,
On 12/09/2013 20:35, Koen Kooi wrote:
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW,
the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1
gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned.
This series d
Hi Tony,
On 13/09/2013 17:27, Tony Lindgren wrote:
* Koen Kooi [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-bo
On Wed, Sep 4, 2013 at 9:03 AM, George Cherian wrote:
> This patch series
> - removes the irq_demux_work
> - Uses devm_request_threaded_irq
> - Call the user handler iff gpio_to_irq is done.
>
> v1 --> v2
> Split v1 to 3 patches
> v2 --> v3
> Remove the unn
Now that there is an _exec version of ioremap, add devm support for it.
Signed-off-by: Russ Dill
---
include/linux/device.h | 17 -
include/linux/io.h | 4 +++
lib/devres.c | 97 --
3 files changed, 114 insertions(+), 4 delet
This patch adds support for and demonstrates the usage of an embedded
position independent executable (PIE). The goal is to allow the use of C
code in situations where carefully written position independent assembly
was previously required.
The example used is the suspend/resume code for the am335
Under certain arches (ARM) function pointers cannot be
used naively. Specifically, for thumb functions, their 0 bit
is set, but they are contained on a word aligned address.
Add a fncpy macro to perform function copies correctly
along with two helpers, fnptr_to_address, and fnptr_translate.
Signe
This commit adds support for embedding PIEs into the kernel, loading them
into genalloc sections, performing necessary relocations, and running code
from them. This allows platforms that need to run code from SRAM, such
an during suspend/resume, to develop that code in C instead of assembly.
Funct
This is necessary for platforms that use SRAM to execute suspend/resume stubs.
Signed-off-by: Russ Dill
---
Documentation/devicetree/bindings/misc/sram.txt | 4
drivers/misc/sram.c | 13 -
include/linux/platform_data/sram.h | 8
This adds support for updating PIE relocations under ARM. This
is necessary in the case that the same PIE must run both with
virtual mapping (MMU enabled) and physical mapping (MMU
disabled).
Signed-off-by: Russ Dill
---
arch/arm/include/asm/pie.h | 42 +
arch/arm/kernel/
Add a helper that generates a short snippet of code that updates PIE
relocations, loads the stack pointer and calls a C (or asm) function.
The code gets placed into a PIE section.
Signed-off-by: Russ Dill
---
arch/arm/include/asm/suspend.h | 25 +
1 file changed, 25 inser
The SRAM is for use by the MPU. Marking it as such makes it
easier for PM initialization code to locate the SRAM in order to
load a PIE section into it.
Additionally, set the map-exec flag to allow code to be run
from SRAM. This is necessary for suspend/resume.
Signed-off-by: Russ Dill
---
arch
Add support to ARM for embedding PIEs into the kernel, loading them into
genalloc pools (such as SRAM) and executing them. Support for ARM means
performing R_ARM_RELATIVE fixups within the .rel.dyn section.
Signed-off-by: Russ Dill
---
arch/arm/Kconfig | 1 +
arch/arm/Makefile
This enables CONFIG_PIE for omap2plus_defconfig and adds
an am33xx PIE section group. This is necessary for am33xx
suspend/resume code as it is written in C.
Signed-off-by: Russ Dill
---
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/kernel/pie.lds.S| 1 +
2 files changed, 2 in
From: Vaibhav Bedia
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend st
If code is to be copied into and area (such as SRAM) and run,
it needs to be marked as exec. Currently only an ARM version
of this exists.
Signed-off-by: Russ Dill
---
arch/arm/include/asm/io.h | 2 ++
include/asm-generic/iomap.h | 5 +
2 files changed, 7 insertions(+)
diff --git a/arch/a
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner wrote:
> So why can't you make use of irq domains and have the whole routing
> business implemented sanely?
>
> What's needed is in gic_init_bases():
>
>if (of_property_read(node, "routable_irqs", &nr_routable_irqs) {
> irq_domain
On 17/09/13 12:38, Mike Turquette wrote:
> Quoting Archit Taneja (2013-09-17 00:06:28)
>> HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
>> existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
>> These funcs are called directly from the hdmi driver rat
Quoting Archit Taneja (2013-09-17 00:06:28)
> HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
> existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
> These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
> function pointer calls.
The HDMI IP in OMAP4 DSS is present in a few other TI SoCs which don't have a
Display Subsystem similar to what's in OMAP. The original driver was designed
to provide ops such that it could be plugged into a different display subsytem
in some other SoC. These other SoCs, however, never got their ba
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
function pointer calls.
Add the PLL library function declarations to ti_hd
The hdmi4 driver has edid macros that aren't used at all. Remove them.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/hdmi4.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index 324ecd0..ab43069 100644
--- a
HDMI wrapper is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing functions from ti_hdmi_4xxx_ip.c to a separate file. These funcs are
called directly from the hdmi driver rather than hdmi_ip_ops funtion pointer
calls.
Add new wrapper funcs which can be used by other hdmi librarie
Split hdmi address space in order to get base addresses of hdmi submodules by
name. This is just a demonstration patch for the hdmi refactoring to work. The
address data should belong to the hdmi DT node.
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ++
After removing wrapper, pll and phy funcs from ti_hdmi_4xxx_ip.c, we are left
with OMAP4 HDMI core functions. Use these directly in hdmi.c rather than using
hdmi_ip_ops. Rename the core functions with a 'hdmi4' suffix.
We used to have hdmi_ip_ops so that one could support HDMI within a TI SoC whic
HDMI PHY is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing functions from ti_hdmi_4xxx_ip.c to a separate file. These funcs are
called directly from the hdmi driver rather than hdmi_ip_ops function pointer
calls.
Add the PHY library function declarations to ti_hdmi.h. These wil
Add flags for the interrupts present in HDMI wrapper block, these will be used
to configure HDMI_IRQENABLE_SET/CLEAR and HDMI_IRQSTATUS registers.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/hdmi_phy.c | 3 ---
drivers/video/omap2/dss/ti_hdmi.h | 15 +++
2 files change
The struct hdmi_ip_data contains information related to HDMI wrapper, PLL, PHY
and core sub-blocks. Now that each of these sub blocks has it's own struct,
hdmi_ip_data serves no purpose. The mutex lock in the struct was also never
used.
Remove this struct to make things cleaner.
Signed-off-by: Ar
The OMAP4 HDMI encoder driver(hdmi4.c) contains timings tables, and helper
functions which can be used as is by the OMAP5/DRA7x encoder driver. Move these
to hdmi_common.c so that it's not replicated in the future.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/Makefile | 4 +-
Keep only OMAP4 HDMI core block related structs and enums in ti_hdmi_4xxx_ip.h,
move the rest to ti_hdmi.h. This holds all library specific data which will be
shared between OMAP4 and OMAP5/DRA7x HDMI encoder drivers.
Move the duplicate register read/write/wait_for_bit_change functions in the hdmi
74 matches
Mail list logo
