dissonant.dev wiki - User contributions [en]

MediaWiki:Sidebar/Category:Sidebar test

2026-03-10T15:27:00Z

Knuxify:

** https://dissonant.dev | Test
*** https://wiki.dissonant.dev | Test 2

MediaWiki:Sidebar/Category:Sidebar test

2026-03-10T15:22:45Z

Knuxify:

** https://dissonant.dev | Test

MediaWiki:Sidebar/Category:Sidebar test

2026-03-10T14:52:39Z

Knuxify:

* https://dissonant.dev | Test

Category:Sidebar test

2026-03-10T14:48:20Z

Knuxify: Created page with "(test page)"

(test page)

Meta:Infrastructure

2026-03-10T14:44:36Z

Knuxify:

This page acts as an overview of dissonant.dev's infrastructure.

== Servers ==

dissonant.dev currently operates on two servers:

* '''<code>franky</code>''' - the main VPS, a [https://www.hetzner.com/ Hetzner] CX22 node. (2x2.1GHz, 4GB RAM, 40GB storage)
* '''<code>pandemonica</code>''' (a.k.a ''pandy'') - tiny VPS hosting fxtumblr/tpmblr.com; kindly provided by [https://sdomi.pl/ sdomi]. (1x4.2GHz, 2GB RAM, 10GB storage)

Decomissioned servers:

* '''<code>arisu</code>''' - the previous main VPS, a [https://homecloud.pl/ homecloud.pl] Cloud VPS M node. They stopped offering Cloud VPS nodes, and moved them to their main offering at a marked-up price, which forced me to reconsider my hosting options. (2x2GHz, 4GB RAM, 80GB storage)

<code>franky</code> is named after Franky from ''Flying Saucer Video''. <code>pandemonica</code> is named after Pandemonica from ''Helltaker'' (I don't even know what that game's about I just thought she was neat). <code>arisu</code> was a Lain reference. I am cringe but I am free.

== Expansion possibilities ==

I would like to look into self-hosting some services from home; the main issue is getting a static IPv4 address, but my ISP provides public IPv6 addresses so that would leave us with having to find a proxy of some sort.

[[Category:Sidebar test]]

MediaWiki:Sidebar

2026-03-10T14:44:01Z

Knuxify:

User:Knuxify/sidebartest

2026-03-10T14:42:43Z

Knuxify: Created page with "This is an example page Category:Sidebar test"

This is an example page
[[Category:Sidebar test]]

MediaWiki:Sidebar/Category:Sidebar test

2026-03-10T14:42:11Z

MediaWiki:Editnotice-notext

2025-10-04T05:48:38Z

Knuxify:

test

MediaWiki:Edittools

2025-10-04T05:48:13Z

Knuxify:

MediaWiki:Edittools

2025-10-04T05:48:05Z

Knuxify:

a

Mainline:Broadcom Kona/BCM590xx

2025-09-15T19:46:32Z

Knuxify:

This '''root page''' connects all pages related to the BCM590xx series of PMICs, in particular the BCM59054 and BCM59056.

The BCM590xx PMICs comprise of the following parts:

* Internal interrupt controller ([[/Interrupts]])
* Regulators ([[/Regulators]])
* Power-on key controller/PONKEY ([[/PONKEY]])
* RTC ([[/RTC]])
* Charger [[/Charger]])
* Fuel gauge ([[/Fuel gauge]])
* USB OTG control ([[/USB]])
* Audio amplifier (?)
* PWM LED controller
* ADC used e.g. for thermal monitoring ([[/ADC]])

== Subpages ==

{{Subpages|stripprefix=true}}

Mainline:Broadcom Kona/BCM590xx/Regulators

2025-09-15T19:46:20Z

Knuxify: Created page with "{{hatnote|Relevant downstream drivers: {{downstream|baffinlite|drivers/regulator/bcmpmu59xxx-regulator.c}}; {{downstream|baffinlite|bcmpmu-regulator.c}}; {{downstream|baffinlite|drivers/regulator/bcm590xx-regulator.c}} and {{downstream|baffinlite|drivers/regulator/bcm59055_regulator.c}} for BCM59055.}} The BCM590xx PMUs have configurable voltage regulators. == Regulator types == There are two types of regulators: '''LDO''' (low dropout) and '''SR''' (switcher). Regula..."

{{hatnote|Relevant downstream drivers: {{downstream|baffinlite|drivers/regulator/bcmpmu59xxx-regulator.c}}; {{downstream|baffinlite|bcmpmu-regulator.c}}; {{downstream|baffinlite|drivers/regulator/bcm590xx-regulator.c}} and {{downstream|baffinlite|drivers/regulator/bcm59055_regulator.c}} for BCM59055.}}

The BCM590xx PMUs have configurable voltage regulators.

== Regulator types ==

There are two types of regulators: '''LDO''' (low dropout) and '''SR''' (switcher). Regulator names are suffixed with these shortcuts to indicate their type (e.g. ''LVLDO1'' is an LDO, ''CSR'' is an SR).

== Operating modes ==

The operating modes for each regulator are stored in <code>PMMODE</code> registers. These registers are used to store operating modes for various '''PC''' (pin control) configurations. The mode that ends up being used is determined based on the state of PC1 and PC2 pins (and optionally the GPIO1 pin, if it's configured to the PC3 function in GPIOCTRL).

'''LDOs''' have '''2-bit modes'''. The available modes are <code>ON</code> (0), <code>LPM</code> (low power mode; 1) and <code>OFF</code> (2). {{speculation|Mode 3 is presumably invalid, but hasn't been tested.}}

'''SRs''' have '''3-bit modes'''. The exact function of each mode is unknown; the vendor kernel does not bother with the distinction and applies the LDO modes described above.

LDOs get 2 PMMODE registers each; SRs get 4 PMMODE registers. This is to accomodate the different mode sizes.

There is no known way to query the state of PC pins from the BCM590xx itself; instead, the SoC's pinmux interface could be used.

== See also ==

* [[User:Knuxify/Old BCM590xx regulator notes|Old BCM590xx regulator notes]], very messy.

User:Knuxify/Old BCM590xx regulator notes

2025-09-15T19:18:25Z

Knuxify: Knuxify moved page Mainline:Broadcom Kona/BCM590xx/Regulators to User:Knuxify/Old BCM590xx regulator notes without leaving a redirect

(note: this article has not been cleaned up ''at all'', it is imported from my local notes as-is.)

== Revisions ==

BCMPMU_59054_ID is ID for 59054

BCMPMU_59054A1_ANA_REV refers to A1 which has ACLD, A0 does not

== Downstream driver notes ==

* The downstream driver used is BCM59xxx, which despite the name is only for the BCM59054
** In the tree there are also drivers for BCM59056, a handful of other PMUs including BCM59055, and BCM590xx (which confusingly is '''not''' the same as BCM59xxx).
* The whole driver is fragmented as it's an MFD device, but the most important files are:
** <code>arch/arm/mach-{codename}/board-bcm59xxx_{device}.c</code> - contains PMU setup data, including voltages, regulator modes, battery values, etc.
** various files in <code>drivers/mfd/</code> starting from <code>bcmpmu59xxx-</code>
** <code>drivers/regulator/bcmpmu-rgltr-bcm59xxx.c</code> and <code>drivers/regulator/bcmpmu59xxx-regulator.c</code>
** there's some OTG related driver in <code>drivers/usb/otg/</code>? investigate
** <code>drivers/misc/bcmpmu59xxx_audio.c</code>
** <code>include/linux/mfd/bcmpmu59xxx_reg.h</code> and <code>include/linux/mfd/bcmpmu59054_reg.h</code>
** and others not mentioned here. todo

== Regulators ==

SR apparently means "switcher" (drivers/regulator/bcmpmu-regulator-56.c line 249). Rest is LDOs.

== Modes ==

''(see <code>drivers/regulator/bcmpmu59xxx-regulator.c</code>, <code>include/linux/mfd/bcmpmu59xxx.h</code>)''

There are two mode settings: 3bit (GPLDOs only) and 2bit (everything else, including all regs in bcm59056).

A standard regulator can have 3 modes: * ON (<code>REGULATOR_MODE_FAST</code>, <code>REGULATOR_MODE_NORMAL</code>) (0) * LPM (<code>REGULATOR_MODE_IDLE</code>) (1) * OFF (<code>REGULATOR_MODE_STANDBY</code>) (2)

* 2-bit mode regulators have 4 PM values in the PMMODE registers, at offsets 0, 2, 4 and 6 respectively (PM0, PM1, PM2, PM3), and '''2 PMMODE registers'''. (PMCTRL1 and PMCTRL2)
* 3-bit mode regulators have 2 PM values in the PMMODE registers, at offsets 0 and 3 respectively, and '''4 PMMODE registers'''. (PMCTRL1->4)

Each PM value corresponds to a different mode.

== BCM59056 and modes ==

''(see <code>drivers/regulator/bcmpmu-regulator-56.c</code>)''

<strike>Unlike BCM59054, there's only one PMMODE register</strike> (this is completely wrong! BCM59056 also has multiple PMMODE regs), and it has values PM0 to PM3. DSM (deep sleep) is pins PM0 and PM2. Regular value is written to PM1 and PM3.

I have a sneaking suspicion, based on the mainline driver, and the fact that the function described in the "Enabling the regulator" part will gleefuly ignore PM0 mostly, that PM0 may be some sort of "perma-override"

<syntaxhighlight lang="c">
/*State of enabled regualtor in deep sleep
Used to program PC2PC1 = 0b10 & 0b00 case
when the regulator is enabled*/
enum {
BCMPMU_REGL_ON_IN_DSM = 1,
BCMPMU_REGL_LPM_IN_DSM,
BCMPMU_REGL_OFF_IN_DSM
};
</syntaxhighlight>

...a PC reference? You'll see these in the next section.

=== BCM59054 and modes ===

Here, the situation is a bit more complicated because there are multiple PMMODE regs. (Actually BCM59056 seems to have these as well? weird.)

=== Enabling a regulator ===

In theory, enabling a regulator can be done by setting all of its modes to <code>PMMODE_ON</code>. In practice, however, each regulator has specific "pins" which, when enabled, will enable the regulator. The pins used are stored in <code>arch/arm/mach-java/board-bcm59xxx_*</code>, under <code>pc_pins_map</code>.

This has a value created with the "PCPIN_MAP_ENC" macro, which effectively packs two "sets":

* '''Set 1''', which is the first parameter - if this is set, then '''all pins in this set must be enabled''' to enable this regulator.
* '''Set 0''', which is the second parameter - if this is set, then '''one of the pins in this set must be enabled''' to enable this regulator.

The functions <code>__is_2bit_pmmode_regl_enabled</code> and <code>__is_3bit_pmmode_regl_enabled</code> check if a regulator is enabled based on those pin maps, and the <code>pmmode</code> value as read out from the PMMODE registers.

For every <code>i</code> from 0 to 7 (<code>REGL_PMMODE_VAL_MAX</code>):

* get the PM reg shift by <code>PMMODE_2BIT_PMx_MASK & i</code> (PMMODE_2BIT_PMx_MASK == 3)
* if this <code>i</code> gives a value through <code>setval & i</code> in set0 or set1, then the value of whether the regulator is enabled is calculated using <code>PMMODE_2BIT_PMx_MASK & (pmmode[inx] >> shift)</code>, where <code>inx</code> is increased for every value where <code>PMMODE_2BIT_PMx_MASK & i</code> == 3.

In normal words: if the mode corresponding to the pin in ''any'' of the PMMODE registers is ON, then the regulator is on.

Here's a table of what that looks like:

(i - i iterator, s - pm offset, x - pmmode register no., set0 - matches against joined set0; pc1, pc2, pc3 - the result of the check for each of the possible pins in set0)

<syntaxhighlight lang="python">i s x set0 pc1 pc2 pc3
0 0 0 False [False, False, False]
1 2 0 True [True, False, False]
2 4 0 True [False, True, False]
3 6 0 True [True, True, False]
4 0 1 True [False, False, True]
5 2 1 True [True, False, True]
6 4 1 True [False, True, True]
7 6 1 True [True, True, True]</syntaxhighlight>
One thing of note - PC1 matches exactly the same configuration as the non-deep-sleep pins from the BCM59056 driver mentioned earlier. PC2 matches offsets 4 and 6, and PC3 matches everything in the second register, but not the first one.

So, how can the BCM59056 driver ignore that second register? Maybe I just didn't read something right? (probably...) (update: I think it's just BCM59054 that pokes multiple regs?)

Update: I found this a little later, in the bcm59'''0xx''' driver (actually for the BCM59055).

<syntaxhighlight lang="c">#define PC2_IS_0_PC1_IS_0 0
#define PC2_IS_0_PC1_IS_1 2
#define PC2_IS_1_PC1_IS_0 4
#define PC2_IS_1_PC1_IS_1 6 </syntaxhighlight>
I suppose this should match the table above?

In any case - what I think is happening here is that which registers are read from to determine the notes are controlled by some kind of pins. Each PMMODE offset represents a different combination of pins to set.

=== The actual function called to prepare the enable value ===

Now that we know how these pins work, we can analyze the second function, <code>__2bit_pmmode_frm_map</code>.

This one's similar to the previous function:

For every <code>i</code> from 0 to 7 (<code>REGL_PMMODE_VAL_MAX</code>):

* If the value is in set0 or set1, set the value to <code>PMMODE_ON</code>; otherwise, use '''<code>dsm_pmmode</code>''' (a variable passed at init time). Oooh, DSM again!
* Figure out the shift and register like before.
* Add the value to a temp variable by ORing <code>val << shift</code> to it.

Here's the thing: <code>dsm_pmmode</code>... is the mode value provided in <code>__bcmpmuldo_set_mode</code>.

The mode is set in a few places in the code, and next to one of them, I found this:

<syntaxhighlight lang="c"> /* We need to set mode here as regulator framework
(set_machine_constraints) set the mode first and
then call enable. We have updated enable function
to set ON for all states based on customer request
set_mode function sets PMMODE as needed*/
</syntaxhighlight>

==== TL;DR, summary ====

Regulators can be enabled by setting specific offsets at the PMMODE registers to PMMODE_ON. A combination of PC pins can be used to select which offsets and PMMODE registers actually apply - by default, only offsets in PMCTRL1 is used, but the others can be used as well if PC3 is present - see below.

As a gross oversimplification, you can simply set ''every'' register to PMMODE_ON and it should work.

PM0 and PM2 (offsets 0 and 4) may or may not be related to deep sleep mode.

== A note about PC pins ==

According to schematics, on the Grand Neo, PC1 and PC2 are connected to the accordingly named PC1 and PC2 pinctrl pins. PC3 is an alternative function of LCDCS0 - and it's connected, as PMU_PC3, to the GPIO1 pin on the PMIC.

Turns out, the function of the GPIO pins can be programmed by writing to the GPIOCTRL registers. Here's the relevant downstream code:

(arch/arm/mach-java/board-bcm59xxx_ss_baffinlite.c)

<syntaxhighlight lang="c"> 121 /* enable PC3 function */
122 {.addr = PMU_REG_GPIOCTRL2, .val = 0x0E, .mask = 0xFF},</syntaxhighlight>
Sadly, these regs are completely undocumented, so we can't know for sure which exact bit enables this function. We also don't know what happens if it's ''not'' enabled.

== What about the regulator modes? ==

Somehow, <code>__2bit_pmmode_frm_map</code> ''doesn't'' set all of the PMMODE offsets! For the offsets matching the PC pin map, it actually ''leaves them on'', and only sets the requested mode for the remaining ones! Given that the variable name for the provided mode is <code>dsm_pmmode</code>, I suspect that Broadcom might've abused the mode system to provide the ''deep sleep regulator mode'' instead.

Still, this doesn't explain how the PC pins are controlled. I can't find any place in the downstream code that would do it. I suspect I should look at the suspend code...

Note to self: CHIPREG seems interesting. Has a whole bunch of stuff.

Another unrelated note: looks like i2c sets up slew rate for its pins in the driver, investigate

Template:Todo/style.css

2025-09-15T18:56:31Z

Knuxify: Created page with "html.skin-theme-clientpref-night .box-todo { color: #fff !important; background-color: #5c1e1e !important; border-color: #c64242 !important; } @media (prefers-color-scheme: dark) { html.skin-theme-clientpref-os .box-todo { color: #fff !important; background-color: #5c1e1e !important; border-color: #c64242 !important; } }"

html.skin-theme-clientpref-night .box-todo {
color: #fff !important;
background-color: #5c1e1e !important;
border-color: #c64242 !important;
}

@media (prefers-color-scheme: dark) {
html.skin-theme-clientpref-os .box-todo {
color: #fff !important;
background-color: #5c1e1e !important;
border-color: #c64242 !important;
}
}

Template:Note/style.css

2025-09-15T18:56:03Z

Knuxify: Created page with "html.skin-theme-clientpref-night .box-note { color: #fff !important; background-color: #261c09 !important; border-color: #6a481c !important; } @media (prefers-color-scheme: dark) { html.skin-theme-clientpref-os .box-note { color: #fff !important; background-color: #261c09 !important; border-color: #6a481c !important; } }"

html.skin-theme-clientpref-night .box-note {
color: #fff !important;
background-color: #261c09 !important;
border-color: #6a481c !important;
}

@media (prefers-color-scheme: dark) {
html.skin-theme-clientpref-os .box-note {
color: #fff !important;
background-color: #261c09 !important;
border-color: #6a481c !important;
}
}

Template:Note

2025-09-15T18:45:42Z

Knuxify: Created page with "<templatestyles src="Note/style.css"/><includeonly>{{Icon box | box-icons = Note | box-text = {{{1}}} | border-color = #ac6600 | border-width = 1px | background = #f6efe5 | class = box-note }}</includeonly><noinclude> <templatedata> { "params": { "1": { "label": "Text", "description": "Text to place in the box", "type": "unbalanced-wikitext",..."

<templatestyles src="Note/style.css"/><includeonly>{{Icon box
| box-icons = [[File:Reference icon.svg|20px|link=|Note]]
| box-text = {{{1}}}
| border-color = #ac6600
| border-width = 1px
| background = #f6efe5
| class = box-note
}}</includeonly><noinclude>
<templatedata>
{
"params": {
"1": {
"label": "Text",
"description": "Text to place in the box",
"type": "unbalanced-wikitext",
"required": true
}
},
"description": "Note box containing a note.",
"format": "inline"
}
</templatedata>

== Example ==

<nowiki>{{note|This is quite '''note-worthy'''.}}</nowiki>

{{note|This is quite '''note-worthy'''.}}
</noinclude>

Mainline:Broadcom Kona/BCM590xx/ADC

2025-08-31T15:37:26Z

Knuxify: /* RTM (Real-Time Measurment) */

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/hwmon/bcmpmu59xxx-hwmon.c}}, {{downstream|baffinlite|drivers/misc/bcm59055-adc.c}} (for BCM59055 but very well commented, and seems to be about the same as other models).}}

The BCM590xx PMUs provide a 10-bit SAR (Successive Approximation) ADC.

== Reading the ADC data ==

Each ADC channel has two registers which immediately succeed each other. These registers follow the layout outlined below.

To read the ADC data, one needs to combine the DATA_MSB bits (upper 2 bits, first two bits of the first register) with the DATA_LSB (lower 8 bits, entire value of the second register). An additional value at bit 2 is available to check the validity of the read data.

<syntaxhighlight lang="c">
data = ((reg1 & 0x3) << 8) | reg2;
</syntaxhighlight>

=== ADCCTRLx ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:3
| Reserved/unknown
|-
| <code>READ_INVALID</code>
| 2
| If 1, the read is invalid; 0 otherwise.
|-
| <code>DATA_MSB</code>
| 1:0
| Upper (most significant) 2 bits of the ADC data.
|}

=== ADCCTRLx+1 ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>DATA_LSB</code>
| 7:0
| Lower (least significant) 8 bits of the ADC data.
|}

== RTM (Real-Time Measurment) ==

The last ADC channel, RTM, is reserved for RTM (Real-Time Measurment) mode.

The process for performing an RTM read is as follows:

* In <code>ADCCTRL1</code>: (these can all be performed in one write)
** Set the the <code>RTM_CONVERSION</code> bit to enable RTM mode
** Write the channel number to read to the <code>RTM_CHANN</code> offset
** Write the <code>RTM_START</code> bit to start the RTM read
* Wait for the <code>ADC_RTM_DATA_READY</code> interrupt.
* Perform a standard data read from the RTM ADC channel registers (see [[#Reading the ADC data]]).
* Clear the <code>RTM_CONVERSION</code> bit to disable RTM mode.

== Register layout ==

Values given here are for the BCM59054. These registers are located on map 1.

=== ADCCTRL1 (0x20) ===

Contains settings for RTM mode.

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>RTM_CHANN</code>
| 7:4
| Channel to read in RTM mode.
|-
| <code>RTM_CONVERSION</code>
| 3
| Enable (0) or disable (1) RTM mode. Prerequisite for performing an RTM read.
|-
| <code>RTM_START</code>
| 2
| When set to 1, starts the RTM reading.
|-
| <code>RTM_MAX_RST_CNT</code>
| 1:0
| Max reset count for RTM mode. Valid values are:
* 0 (0b00) - 1
* 1 (0b01) - 3
* 2 (0b10) - 5
* 3 (0b11) - 7
|}

=== ADCCTRL2 (0x21) ===

{{note|These are taken from the BCM59055 driver, and haven't been tested on the BCM59054 yet. {{Speculation|Still, given that the ADCCTRL1 layout is the same, I suspect this one should be the same as well...}}}}

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:6
| Reserved/unknown
|-
| <code>GSM_DEBOUNCE</code>
| 5
| If set to 1, enables ADC burst mode (todo, how does it work?).
|-
| <code>RTM_DLY</code>
| 4:0
| RTM read delay. Valid values:
* 0 (0b00000) - 0ns
* 1 (0b00001) - 31.25ns
* 2 (0b00010) - 62.50ns
* 3 (0b00011) - 93.75ns
* 4 (0b00100) - 125ns
* 5 (0b00101) - 156.25ns
* 6 (0b00110) - 187.50ns
* 7 (0b00111) - 218.75ns
* 8 (0b01000) - 250ns
* 9 (0b01001) - 281.25ns
* 10 (0b01010) - 312.50ns
* 11 (0b01011) - 343.75ns
* 12 (0b01100) - 375ns
* 13 (0b01101) - 406.25ns
* 14 (0b01110) - 437.50ns
* 15 (0b01111) - 468.75ns
* 16 (0b10000) - 500ns
* 17 (0b10001) - 531.25ns
* 18 (0b10010) - 562.50ns
* 19 (0b10011) - 593.75ns
* 20 (0b10100) - 625ns
* 21 (0b10101) - 656.25ns
* 22 (0b10110) - 687.50ns
* 23 (0b10111) - 718.75ns
* 24 (0b11000) - 750ns
* 25 (0b11001) - 781.25ns
* 26 (0b11010) - 812.50ns
* 27 (0b11011) - 843.75ns
* 28 (0b11100) - 875ns
* 29 (0b11101) - 906.25ns
* 30 (0b11110) - 937.50ns
* 31 (0b11111) - 968.75ns
|}

=== ADCCTRL3 - ADCCTRL28 ===

ADC channel registers; see layout above.

=== ADCCTRL29 and ADCCTRL30 ===

Unknown.

Mainline:Broadcom Kona/BCM590xx/ADC

2025-08-31T15:34:27Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/hwmon/bcmpmu59xxx-hwmon.c}}, {{downstream|baffinlite|drivers/misc/bcm59055-adc.c}} (for BCM59055 but very well commented, and seems to be about the same as other models).}}

The BCM590xx PMUs provide a 10-bit SAR (Successive Approximation) ADC.

== Reading the ADC data ==

Each ADC channel has two registers which immediately succeed each other. These registers follow the layout outlined below.

To read the ADC data, one needs to combine the DATA_MSB bits (upper 2 bits, first two bits of the first register) with the DATA_LSB (lower 8 bits, entire value of the second register). An additional value at bit 2 is available to check the validity of the read data.

<syntaxhighlight lang="c">
data = ((reg1 & 0x3) << 8) | reg2;
</syntaxhighlight>

=== ADCCTRLx ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:3
| Reserved/unknown
|-
| <code>READ_INVALID</code>
| 2
| If 1, the read is invalid; 0 otherwise.
|-
| <code>DATA_MSB</code>
| 1:0
| Upper (most significant) 2 bits of the ADC data.
|}

=== ADCCTRLx+1 ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>DATA_LSB</code>
| 7:0
| Lower (least significant) 8 bits of the ADC data.
|}

== RTM (Real-Time Measurment) ==

The last ADC channel, RTM, is reserved for RTM (Real-Time Measurment) mode.

The process for performing an RTM read is as follows:

* In <code>ADCCTRL1</code>: (these can all be performed in one write)
** Set the the <code>RTM_CONVERSION</code> bit to enable RTM mode
** Write the channel number to read to the <code>RTM_CHAN</code> offset
** Write the <code>RTM_START</code> bit to start the RTM read
* Wait for the <code>ADC_RTM_DATA_READY</code> interrupt.
* Perform a standard data read from the RTM ADC channel registers (see [[#Reading the data]]).
* Clear the <code>RTM_CONVERSION</code> bit to disable RTM mode.

== Register layout ==

Values given here are for the BCM59054. These registers are located on map 1.

=== ADCCTRL1 (0x20) ===

Contains settings for RTM mode.

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>RTM_CHANN</code>
| 7:4
| Channel to read in RTM mode.
|-
| <code>RTM_CONVERSION</code>
| 3
| Enable (0) or disable (1) RTM mode. Prerequisite for performing an RTM read.
|-
| <code>RTM_START</code>
| 2
| When set to 1, starts the RTM reading.
|-
| <code>RTM_MAX_RST_CNT</code>
| 1:0
| Max reset count for RTM mode. Valid values are:
* 0 (0b00) - 1
* 1 (0b01) - 3
* 2 (0b10) - 5
* 3 (0b11) - 7
|}

=== ADCCTRL2 (0x21) ===

{{note|These are taken from the BCM59055 driver, and haven't been tested on the BCM59054 yet. {{Speculation|Still, given that the ADCCTRL1 layout is the same, I suspect this one should be the same as well...}}}}

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:6
| Reserved/unknown
|-
| <code>GSM_DEBOUNCE</code>
| 5
| If set to 1, enables ADC burst mode (todo, how does it work?).
|-
| <code>RTM_DLY</code>
| 4:0
| RTM read delay. Valid values:
* 0 (0b00000) - 0ns
* 1 (0b00001) - 31.25ns
* 2 (0b00010) - 62.50ns
* 3 (0b00011) - 93.75ns
* 4 (0b00100) - 125ns
* 5 (0b00101) - 156.25ns
* 6 (0b00110) - 187.50ns
* 7 (0b00111) - 218.75ns
* 8 (0b01000) - 250ns
* 9 (0b01001) - 281.25ns
* 10 (0b01010) - 312.50ns
* 11 (0b01011) - 343.75ns
* 12 (0b01100) - 375ns
* 13 (0b01101) - 406.25ns
* 14 (0b01110) - 437.50ns
* 15 (0b01111) - 468.75ns
* 16 (0b10000) - 500ns
* 17 (0b10001) - 531.25ns
* 18 (0b10010) - 562.50ns
* 19 (0b10011) - 593.75ns
* 20 (0b10100) - 625ns
* 21 (0b10101) - 656.25ns
* 22 (0b10110) - 687.50ns
* 23 (0b10111) - 718.75ns
* 24 (0b11000) - 750ns
* 25 (0b11001) - 781.25ns
* 26 (0b11010) - 812.50ns
* 27 (0b11011) - 843.75ns
* 28 (0b11100) - 875ns
* 29 (0b11101) - 906.25ns
* 30 (0b11110) - 937.50ns
* 31 (0b11111) - 968.75ns
|}

=== ADCCTRL3 - ADCCTRL28 ===

ADC channel registers; see layout above.

=== ADCCTRL29 and ADCCTRL30 ===

Unknown.

Mainline:Broadcom Kona/BCM590xx/ADC

2025-08-31T15:26:40Z

Knuxify: /* RTM (Real-Time Measurment) */

Mainline:Broadcom Kona/BCM590xx/ADC

2025-08-31T14:58:15Z

Knuxify:

Mainline:Broadcom Kona/BCM590xx/ADC

2025-08-31T14:56:28Z

Knuxify: Created page with "{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/hwmon/bcmpmu59xxx-hwmon.c}}, {{downstream|baffinlite|drivers/misc/bcm59055-adc.}} (for BCM59055 but very well commented, and seems to be about the same as other models).}} The BCM590xx PMUs provide a 10-bit SAR (Successive Approximation) ADC. == Reading the ADC data == Each ADC channel has two registers which immediately succeed each other. These registers follow the layout outlined below. To read the ADC d..."

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/hwmon/bcmpmu59xxx-hwmon.c}}, {{downstream|baffinlite|drivers/misc/bcm59055-adc.}} (for BCM59055 but very well commented, and seems to be about the same as other models).}}

The BCM590xx PMUs provide a 10-bit SAR (Successive Approximation) ADC.

== Reading the ADC data ==

Each ADC channel has two registers which immediately succeed each other. These registers follow the layout outlined below.

To read the ADC data, one needs to combine the DATA_MSB bits (upper 2 bits, first two bits of the first register) with the DATA_LSB (lower 8 bits, entire value of the second register). An additional value at bit 2 is available to check the validity of the read data.

<syntaxhighlight lang="c">
data = ((reg1 & 0x3) << 8) | reg2;
</syntaxhighlight>

=== ADCCTRLx ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:3
| Reserved/unknown
|-
| <code>READ_INVALID</code>
| 2
| If 1, the read is invalid; 0 otherwise.
|-
| <code>DATA_MSB</code>
| 1:0
| Upper (most significant) 2 bits of the ADC data.
|}

=== ADCCTRLx+1 ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>DATA_LSB</code>
| 7:0
| Lower (least significant) 8 bits of the ADC data.
|}

== RTM (Real-Time Measurment) ==

The last ADC channel, RTM, is reserved for RTM (Real-Time Measurment) mode.

Mainline:Broadcom Kona/BCM590xx

2025-08-31T14:45:25Z

Knuxify:

This '''root page''' connects all pages related to the BCM590xx series of PMICs, in particular the BCM59054 and BCM59056.

The BCM590xx PMICs comprise of the following parts:

* Internal interrupt controller ([[/Interrupts]])
* Regulators ([[/Regulators]] - WIP article, needs updates)
* Power-on key controller/PONKEY ([[/PONKEY]])
* RTC ([[/RTC]])
* Charger [[/Charger]])
* Fuel gauge ([[/Fuel gauge]])
* USB OTG control ([[/USB]])
* Audio amplifier (?)
* PWM LED controller
* ADC used e.g. for thermal monitoring ([[/ADC]])

== Subpages ==

{{Subpages|stripprefix=true}}

Mainline:Broadcom Kona/BCM590xx/USB

2025-08-27T13:11:27Z

Knuxify:

{{Hatnote|Downstream drivers: {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy-core.c}}, {{downstream|baffinlite|bcmpmu59xxx-accy-detect.c}}, {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy.c}} which is unused?, {{downstream|baffinlite|drivers/mfd/bcm590xx-usb.c}} for the BCM59055; {{downstream|baffinlite|drivers/usb/otg/bcm_otg_adp.c}}, {{downstream|baffinlite|drivers/usb/otg/bcmpmu59xxx_otg_xceiv.c}}, and to some extent external MUIC drivers which hook into the BCM59xxx drivers:}}

The BCM590xx PMUs are capable of USB port management and cable detection.

== Glossary ==

Some terms get mentioned repeatedly in USB OTG code. These are common terms related to either the USB 2.0 spec or the USB OTG spec, and appear often in other drivers as well.

* '''VBUS''' - the 5V power rail in an USB cable. When the device is charging or plugged in as a peripheral (e.g. to a computer), the voltage is provided by the charger; when an USB OTG dongle is plugged in (the device operates in host mode), it needs to provide its own voltage. Most PMUs, the BCM590xx included, provide a "VBUS boost" (''VBUSB'') mode to enable VBUS from the device for host mode and disable it for peripheral mode/charging.
* '''ID''' - The ID pin on the microUSB connector. A floating (not connected to ground) ID pin indicates that the device is to be connected as a peripheral; a grounded ID pin indicates the device should act as the host, and different resistance values between GND and ID can be used to switch between different device types (per the USB Carkit standard).
* '''ADP''' - From USB OTG docs: "The Attach Detection Protocol (ADP) allows an SRP-capable Targeted Host or peripheral-only B-device to detect when a remote device has been attached or detached when VBUS is not present."<ref>https://ia601605.us.archive.org/7/items/usb_20_202303/USB_OTG_and_EH_2-0-version%201_1a.pdf section 5.4.</ref>
* '''SRP''' - Stands for ''Session Request Protocol''. An SRP request can be sent by an USB peripheral to the host device to enable VBUS.
* '''BC1.2''' - the [https://www.usb.org/document-library/battery-charging-v12-spec-and-adopters-agreement USB Battery Charging 1.2 specification]. (Code might use "BC" or "BC12" to refer to it.)

Mainline:Broadcom Kona/BCM590xx/USB

2025-08-27T13:01:33Z

Knuxify:

Mainline:Broadcom Kona/BCM590xx/USB

2025-08-27T08:07:28Z

Knuxify: /* Glossary */

{{Hatnote|Downstream drivers: {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy-core.c}}, {{downstream|baffinlite|bcmpmu59xxx-accy-detect.c}}, {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy.c}} which is unused?, {{downstream|baffinlite|drivers/mfd/bcm590xx-usb.c}} for the BCM59055.}}

The BCM590xx PMUs are capable of USB port management and cable detection.

== Glossary ==

Some terms get mentioned repeatedly in USB OTG code. These are common terms related to either the USB 2.0 spec or the USB OTG spec, and appear often in other drivers as well.

* '''VBUS''' - the 5V power rail in an USB cable. When the device is charging or plugged in as a peripheral (e.g. to a computer), the voltage is provided by the charger; when an USB OTG dongle is plugged in (the device operates in host mode), it needs to provide its own voltage. Most PMUs, the BCM590xx included, provide a "VBUS boost" (''VBUSB'') mode to enable VBUS from the device for host mode and disable it for peripheral mode/charging.
* '''ID''' - The ID pin on the microUSB connector. A floating (not connected to ground) ID pin indicates that the device is to be connected as a peripheral; a grounded ID pin indicates the device should act as the host, and different resistance values between GND and ID can be used to switch between different device types (per the USB Carkit standard).
* '''ADP''' - From USB OTG docs: "The Attach Detection Protocol (ADP) allows an SRP-capable Targeted Host or peripheral-only B-device to detect when a remote device has been attached or detached when VBUS is not present."<ref>https://ia601605.us.archive.org/7/items/usb_20_202303/USB_OTG_and_EH_2-0-version%201_1a.pdf section 5.4.</ref>
* '''SRP''' - Stands for ''Session Request Protocol''. An SRP request can be sent by an USB peripheral to the host device to enable VBUS.

Mainline:Broadcom Kona/BCM590xx/USB

2025-08-27T06:22:11Z

Knuxify: Created page with "{{Hatnote|Downstream drivers: {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy-core.c}}, {{downstream|baffinlite|bcmpmu59xxx-accy-detect.c}}, {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy.c}} which is unused?, {{downstream|baffinlite|drivers/mfd/bcm590xx-usb.c}} for the BCM59055.}} The BCM590xx PMUs are capable of USB port management and cable detection. == Glossary == Some terms get mentioned repeatedly in USB OTG code. These are common terms related to ei..."

{{Hatnote|Downstream drivers: {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy-core.c}}, {{downstream|baffinlite|bcmpmu59xxx-accy-detect.c}}, {{downstream|baffinlite|drivers/mfd/bcmpmu59xxx-accy.c}} which is unused?, {{downstream|baffinlite|drivers/mfd/bcm590xx-usb.c}} for the BCM59055.}}

The BCM590xx PMUs are capable of USB port management and cable detection.

== Glossary ==

Some terms get mentioned repeatedly in USB OTG code. These are common terms related to either the USB 2.0 spec or the USB OTG spec, and appear often in other drivers as well.

* '''VBUS''' - the 5V power rail in an USB cable. When the device is charging or plugged in as a peripheral (e.g. to a computer), the voltage is provided by the charger; when an USB OTG dongle is plugged in (the device operates in host mode), it needs to provide its own voltage. Most PMUs, the BCM590xx included, provide a "VBUS boost" (''VBUSB'') mode to enable VBUS from the device for host mode and disable it for peripheral mode/charging.
* '''ID''' - The ID pin on the microUSB connector. A floating (not connected to ground) ID pin indicates that the device is to be connected as a peripheral; a grounded ID pin indicates the device should act as the host, and different resistance values between GND and ID can be used to switch between different device types (per the USB Carkit standard).
* '''ADP''' - From USB OTG docs: "The Attach Detection Protocol (ADP) allows an SRP-capable Targeted Host or peripheral-only B-device to detect when a remote device has been attached or detached when VBUS is not present."<ref>https://ia601605.us.archive.org/7/items/usb_20_202303/USB_OTG_and_EH_2-0-version%201_1a.pdf section 5.4.</ref>
* '''SRP''' - Stands for ''Session Request Protocol''.

Mainline:Broadcom Kona/BCM590xx/PONKEY

2025-08-17T09:56:37Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/input/misc/bcmpmu59xxx_ponkey.c}}}}

The BCM590XX PMU can handle a power-on key (the responsible section is nicknamed PONKEY).

== Key press detection ==

When a key is pressed, the internal IRQ for a key press (BCM59054_IRQ_POK_PRESSED/BCM59056_IRQ_PONKEYB_F) is raised; when it is released, the internal IRQ for a key release (BCM59054_IRQ_POK_RELEASED/BCM59056_IRQ_PONKEYB_R) is raised. A driver can interpret these IRQs to toggle a key on/off (in downstream, it's wired up to <code>KEY_POWER</code> by default.

=== Debounce interval ===

A debounce interval can be configured independently for button press and release. The debounce values are 3 bits wide and stored in <code>PONKEYCTRL1</code>.

For the BCM59054/BCM59056, the allowed values are 330ns, 1.2ms, 10ms, 50ms, 100ms, 500ms, 1000ms and 2000ms. For the BCM59039/BCM59042/BCM59055, the allowed values are undocumented, but different from BCM59054/56 - <code>3</code> is equal to 100ms (whereas it's 50ms on 54/56).

== Timer ==

TODO. Seems like it might be possible to control long-press function using a timer (one of "poweroff", "restart" or "smart reset"). [https://github.com/knuxdroid/android_kernel_samsung_baffinlite/blob/cm-12.1/drivers/input/misc/bcmpmu59xxx_ponkey.c#L204-L277 Relevant kernel sources], notably commented out.

== Registers (BCM59054) ==

{{hatnote|See {{downstream|baffinlite|include/linux/mfd/bcmpmu59054_reg.h}}.}}

All of them are on MAP0.

=== PONKEYCTRL1 (0x08) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7
| Reserved/unknown
|-
| <code>RELEASE_DEB</code>
| 5:3
| Represents the release debounce.
|-
| <code>PRESS_DEB</code>
| 2:0
| Represents the press debounce.
|}

=== PONKEYCTRL2 (0x09) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>TX1_ACTION</code>
| 7:6
| TODO
|-
| <code>TX1_DLY</code>
| 5:3
| TODO
|-
| <code>TX1_DEB</code>
| 2:0
| TODO
|}

=== PONKEYCTRL3 (0x0A) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>TX2_ACTION</code>
| 7:6
| TODO
|-
| <code>TX2_DLY</code>
| 5:3
| TODO
|-
| <code>TX2_DEB</code>
| 2:0
| TODO
|}

=== PONKEYCTRL4 (0x0B) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7
| Reserved/unknown
|-
| <code>KEY_PAD_LOCK_MODE</code>
| 6
| TODO
|-
| <code>KEY_PAD_LOCK</code>
| 5
| TODO
|-
| <code>POK_RESTART_EN</code>
| 4
| TODO
|-
| Reserved/unknown
| 3
| Reserved/unknown
|-
| <code>POK_WAKUP_DEB</code>
| 2:0
| TODO
|}

=== PONKEYCTRL5 (0x0C) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

=== PONKEYCTRL6 (0x0D) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:5
| Reserved/unknown
|-
| <code>SMART_RST_DLY</code>
| 4:3
| TODO
|-
| <code>SMART_RST_STATUS</code>
| 2
| TODO
|-
| <code>SMART_RST_PWR_EN</code>
| 1
| TODO
|-
| <code>SMART_RST_EN</code>
| 0
| TODO
|}

=== PONKEYCTRL7 (0x0E) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

=== PONKEYCTRL8 (0x0F) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>TX3_ACTION</code>
| 7:6
| TODO
|-
| <code>TX3_DLY</code>
| 5:3
| TODO
|-
| <code>TX3_DEB</code>
| 2:0
| TODO
|}

Template:Todo

2025-08-17T09:39:41Z

Knuxify: Created page with "<templatestyles src="Todo/style.css"/><includeonly>{{Icon box | box-icons = TODO | box-text = TODO: {{{1}}} | border-color = #b60000 | border-width = 1px | background = #fdd1d1 | class = box-todo }}{{#if: {{{nocategory|}}}||Category:To-do items}}</includeonly><noinclude> <templatedata> { "params": { "1": { "label": "Text"..."

<templatestyles src="Todo/style.css"/><includeonly>{{Icon box
| box-icons = [[File:Red warning icon.svg|20px|link=|TODO]]
| box-text = TODO: {{{1}}}
| border-color = #b60000
| border-width = 1px
| background = #fdd1d1
| class = box-todo
}}{{#if: {{{nocategory|}}}||[[Category:To-do items]]}}</includeonly><noinclude>
<templatedata>
{
"params": {
"1": {
"label": "Text",
"description": "Text to place in the box",
"type": "unbalanced-wikitext",
"required": true
},
"nocategory": {
"label": "No category",
"description": "If true/yes, do not add this page to the \"To-do items\" category.",
"type": "boolean"
}
},
"description": "TODO box containing a to-do item. Also adds the page to the \"To-do items\" category; this behavior can be disabled with the \"nocategory\" parameter.",
"format": "inline"
}
</templatedata>

== Example ==

<nowiki>{{todo|This is '''yet to be done'''.}}</nowiki>

{{todo|This is '''yet to be done'''.|nocategory=yes}}
</noinclude>

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T17:41:04Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x07
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. The masks are enforced by hardware - any bit written outside of the mask gets ignored.

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0).

If the date overflows (1 second after 2255-12-31 23:59:59), the clock returns to 2255-12-01 00:00:00.

=== Adjustment IRQ ===

There is an RTCADJ IRQ that is supposed to fire when the RTC value is invalid (at least according to the comments of the downstream driver, and the downstream BCM59055 RTC driver). However, I haven't been able to get it to fire in my testing.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/PONKEY

2025-08-15T17:32:35Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/input/misc/bcmpmu59xxx_ponkey.c}}}}

The BCM590XX PMU can handle a power-on key (the responsible section is nicknamed PONKEY).

== Key press detection ==

When a key is pressed, the internal IRQ for a key press (BCM59054_IRQ_POK_PRESSED/BCM59056_IRQ_PONKEYB_F) is raised; when it is released, the internal IRQ for a key release (BCM59054_IRQ_POK_RELEASED/BCM59056_IRQ_PONKEYB_R) is raised. A driver can interpret these IRQs to toggle a key on/off (in downstream, it's wired up to <code>KEY_POWER</code> by default.

=== Debounce interval ===

A debounce interval can be configured independently for button press and release. The debounce values are 3 bits wide and stored in <code>PONKEYCTRL1</code>.

For the BCM59054/BCM59056, the allowed values are 330ns, 1.2ms, 10ms, 50ms, 100ms, 500ms, 1000ms and 2000ms. For the BCM59039/BCM59042/BCM59055, the allowed values are undocumented, but different from BCM59054/56 - <code>3</code> is equal to 100ms (whereas it's 50ms on 54/56).

== Timer ==

TODO. Seems like it might be possible to control long-press function using a timer (one of "poweroff", "restart" or "smart reset"). [https://github.com/knuxdroid/android_kernel_samsung_baffinlite/blob/cm-12.1/drivers/input/misc/bcmpmu59xxx_ponkey.c#L204-L277 Relevant kernel sources], notably commented out.

== Registers (BCM59054) ==

{{hatnote|See {{downstream|baffinlite|include/linux/mfd/bcmpmu59054_reg.h}}.}}

All of them are on MAP0.

=== PONKEYCTRL1 (0x08) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7
| Reserved/unknown
|-
| <code>RELEASE_DEB</code>
| 5:3
| Represents the release debounce.
|-
| <code>PRESS_DEB</code>
| 2:0
| Represents the press debounce.
|}

=== PONKEYCTRL2 (0x09) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>TX_ACTION</code>
| 7:6
| TODO
|-
| <code>TX_DLY</code>
| 5:3
| TODO
|-
| <code>TX_DEB</code>
| 2:0
| TODO
|}

=== PONKEYCTRL3 (0x0A) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

=== PONKEYCTRL4 (0x0B) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7
| Reserved/unknown
|-
| <code>KEY_PAD_LOCK_MODE</code>
| 6
| TODO
|-
| <code>KEY_PAD_LOCK</code>
| 5
| TODO
|-
| <code>POK_RESTART_EN</code>
| 4
| TODO
|-
| Reserved/unknown
| 3
| Reserved/unknown
|-
| <code>POK_WAKUP_DEB</code>
| 2:0
| TODO
|}

=== PONKEYCTRL5 (0x0C) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

=== PONKEYCTRL6 (0x0D) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:5
| Reserved/unknown
|-
| <code>SMART_RST_DLY</code>
| 4:3
| TODO
|-
| <code>SMART_RST_STATUS</code>
| 2
| TODO
|-
| <code>SMART_RST_PWR_EN</code>
| 1
| TODO
|-
| <code>SMART_RST_EN</code>
| 0
| TODO
|}

=== PONKEYCTRL7 (0x0E) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

=== PONKEYCTRL8 (0x0F) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| Reserved/unknown
| 7:0
| Reserved/unknown
|}

Mainline:Broadcom Kona/BCM590xx/PONKEY

2025-08-15T17:16:30Z

Knuxify:

The BCM590XX PMU can handle a power-on key (the responsible section is nicknamed PONKEY).

== Key press detection ==

When a key is pressed, the internal IRQ for a key press (BCM59054_IRQ_POK_PRESSED/BCM59056_IRQ_PONKEYB_F) is raised; when it is released, the internal IRQ for a key release (BCM59054_IRQ_POK_RELEASED/BCM59056_IRQ_PONKEYB_R) is raised. A driver can interpret these IRQs to toggle a key on/off (in downstream, it's wired up to <code>KEY_POWER</code> by default.

=== Debounce interval ===

A debounce interval can be configured independently for button press and release. The debounce values are 3 bits wide and stored in <code>PONKEYCTRL1</code>.

For the BCM59054/BCM59056, the allowed values are 330ns, 1.2ms, 10ms, 50ms, 100ms, 500ms, 1000ms and 2000ms. For the BCM59039/BCM59042/BCM59055, the allowed values are undocumented, but different from BCM59054/56 - <code>3</code> is equal to 100ms (whereas it's 50ms on 54/56).

== Timer ==

TODO. Seems like it might be possible to control long-press function using a timer (one of "poweroff", "restart" or "smart reset"). [https://github.com/knuxdroid/android_kernel_samsung_baffinlite/blob/cm-12.1/drivers/input/misc/bcmpmu59xxx_ponkey.c#L204-L277 Relevant kernel sources], notably commented out.

{{Subpages}}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:57:56Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x07
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. The masks are enforced by hardware - any bit written outside of the mask gets ignored.

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

If the date overflows (1 second after 2255-12-31 23:59:59), the clock returns to 2255-12-01 00:00:00.

=== Adjustment IRQ ===

There is an RTCADJ IRQ that is supposed to fire when the RTC value is invalid (at least according to the comments of the downstream driver, and the downstream BCM59055 RTC driver). However, I haven't been able to get it to fire in my testing.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:47:29Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x07
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. In the time registers, the masks are enforced by hardware - any bit written outside of the mask gets ignored.

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

If the date overflows (1 second after 2255-12-31 23:59:59), the clock returns to 2255-12-01 00:00:00.

=== Adjustment IRQ ===

There is an RTCADJ IRQ that is supposed to fire when the RTC value is invalid (at least according to the comments of the downstream driver, and the downstream BCM59055 RTC driver). However, I haven't been able to get it to fire in my testing.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:45:20Z

Knuxify: /* Getting the time */

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x07
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. In the time registers, the masks are enforced by hardware - any bit written outside of the mask gets ignored.

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

If the date overflows (1 second after 2255-12-31 23:59:59), the clock returns to 2255-12-01 00:00:00.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:44:06Z

Knuxify: /* Time data */

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x07
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. In the time registers, the masks are enforced by hardware - any bit written outside of the mask gets ignored.

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:38:57Z

Knuxify: /* Time data */

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|0x0F
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers. In the time registers, the masks are enforced by hardware - any bit written outside of the mask gets ignored.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T12:21:16Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|{{speculation|0x0F}}
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0). In this state, the RTCADJ interrupt will be raised.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-15T10:53:41Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Mask
!Value
|-
|0
|Second (<code>SC</code>)
|0x3F
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|0x3F
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|0x1F
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|{{speculation|0x0F}}
|Day of week, from 0 to 6. Appears to roll over whenever the day changes; {{speculation|the hardware does not enforce a specific start.}} Sets itself to 0 on reset. '''Not used in downstream.''' {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|0x1F
|Day of month, starting from 1. Sets itself to 0 on reset.
|-
|5
|Month (<code>MT_WD</code>)
|0x0F
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|0xFF
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0).

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-14T06:43:41Z

Knuxify: /* Getting the time */

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second (<code>SC</code>)
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|Day of week, from 0 to 6. {{speculation|Appears to roll over whenever the day changes; the hardware does not enforce a specific start.}} Sets itself to 0 on reset. {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|Day of month, starting from 1. {{speculation|Sets itself to 0 on reset.}}
|-
|5
|Month (<code>MT_WD</code>)
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is <code>0 0 0 0 0 1 7</code> (2007-01-00 00:00:00, weekday 0). Notably, the day of month is invalid (0).

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-14T06:03:50Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second (<code>SC</code>)
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|Day of week, from 0 to 6. {{speculation|Appears to roll over whenever the day changes; the hardware does not enforce a specific start.}} Sets itself to 0 on reset. {{speculation|The day of month sets itself to 0 on reset, which should be an invalid value, but would suggest that the range is 0 -> Sunday, 6 -> Monday, but there is no downstream code to confirm this.}}
|-
|4
|Day of month (<code>DT</code>)
|Day of month, starting from 1. {{speculation|Sets itself to 0 on reset.}}
|-
|5
|Month (<code>MT_WD</code>)
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is 2007-01-01 at 00:00:00.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-14T05:41:09Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second (<code>SC</code>)
|Current second, from 0 to 59.
|-
|1
|Minute (<code>MN</code>)
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour (<code>HR</code>)
|Current hour of the day, from 0 to 23.
|-
|3
|Weekday (<code>WD</code>)
|Day of week; 0 is Monday, 6 is Sunday. {{speculation|todo, verify}}
|-
|4
|Day of month (<code>DT</code>)
|Day of month, starting from 0.
|-
|5
|Month (<code>MT_WD</code>)
|Number of the month. 1 to 12 represent January-December.
|-
|6
|Year (<code>YR</code>)
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

The default reset value is 2007-01-01 at 00:00:00.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-13T18:06:11Z

Knuxify:

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/rtc/rtc-bcmpmu59xxx.c}}}}

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second
|Current second, from 0 to 59.
|-
|1
|Minute
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour
|Current hour of the day, from 0 to 23.
|-
|3
|Day of month
|Day of month, starting from 0.
|-
|4
|Month
|Number of the month. Sets itself to 0 on reset; 1 to 12 represent January-December. {{speculation|...or does it? The downstream driver would suggest so, but it seems weird. Investigate.}}
|-
|5
|Year
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-13T18:04:49Z

Knuxify:

The BCM590XX PMUs provide a real-time clock.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second
|Current second, from 0 to 59.
|-
|1
|Minute
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour
|Current hour of the day, from 0 to 23.
|-
|3
|Day of month
|Day of month, starting from 0.
|-
|4
|Month
|Number of the month. Sets itself to 0 on reset; 1 to 12 represent January-December. {{speculation|...or does it? The downstream driver would suggest so, but it seems weird. Investigate.}}
|-
|5
|Year
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

This exact format is used for both the time and alarm registers.

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Getting the time ==

On the BCM59054 and BCM59056, time registers start at 0xE0 and follow the format outlined above.

There are interrupts for updates of each of the time values.

== Alarm ==

On the BCM59054 and BCM59056, the alarm registers start at 0xE7.

There is an interrupt that is triggered when the alarm is triggered.

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-13T14:17:09Z

Knuxify: /* Time data */

The RTC is located at register 0xe0 on the BCM59054/BCM59056.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second
|Current second, from 0 to 59.
|-
|1
|Minute
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour
|Current hour of the day, from 0 to 23.
|-
|3
|Day of month
|Day of month, starting from 0.
|-
|4
|Month
|Number of the month. Sets itself to 0 on reset; 1 to 12 represent January-December. {{speculation|...or does it? The downstream driver would suggest so, but it seems weird. Investigate.}}
|-
|5
|Year
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

TODO: What happens on year overflow? Is there a reason as to why the downstream driver limits the values it gets?

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Mainline:Broadcom Kona/BCM590xx/RTC

2025-08-13T14:13:06Z

Knuxify: Created page with "The RTC is located at register 0xe0 on the BCM59054/BCM59056. == Time data == The RTC stores the time in the following format: {|class="wikitable bittable" !Offset !Purpose !Value |- |0 |Second |Current second, from 0 to 59. |- |1 |Minute |Current minute of the hour, from 0 to 59. |- |2 |Hour |Current hour of the day, from 0 to 23. |- |3 |Day of month |Day of month, starting from 0. |- |4 |Month |Number of the month. Sets itself to 0 on reset; 1 to 12 represent Januar..."

The RTC is located at register 0xe0 on the BCM59054/BCM59056.

== Time data ==

The RTC stores the time in the following format:

{|class="wikitable bittable"
!Offset
!Purpose
!Value
|-
|0
|Second
|Current second, from 0 to 59.
|-
|1
|Minute
|Current minute of the hour, from 0 to 59.
|-
|2
|Hour
|Current hour of the day, from 0 to 23.
|-
|3
|Day of month
|Day of month, starting from 0.
|-
|4
|Month
|Number of the month. Sets itself to 0 on reset; 1 to 12 represent January-December. {{speculation|...or does it? The downstream driver would suggest so, but it seems weird. Investigate.}}
|-
|5
|Year
|Amount of years since 2000 (0 = 2000, 1 = 2001, etc.)
|}

== Calibration ==

{{hatnote|Downstream driver: {{downstream|baffinlite|drivers/char/broadcom/rtc_cal/bcm_rtc_cal.c}}}}

There are three calibration registers: CALIB1, CALIB2 and CALIB3.

{{todo|Figure out how the calibration process works, this is just my initial idea}}

{{speculation|Calibration appears to be triggered based on a CP (communications processor) event; it receives a message from the CP and uses a value from it as the "ratio".}} The ratio value is then compared against <code>RTCCAL_Ratio</code> (taken from <code>rtccal_data.nom_ratio</code>, <code>8666667</code>); if <code>ratio > RTCCAL_Ratio</code>, then direction is 1, otherwise it's 0.

The <code>clk_val</code> value is then calculated based on the difference between the new and old ratio (<code>diff = abs(ratio - RTCCAL_Ratio)</code>): <code>clk_val = RTCCAL_Ratio / diff</code>.

TODO - what is the ratio value?

=== CALIB1 (0xF4) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (1)
| 7:0
| Lower 8 bits of the calibration offset.
|}

=== CALIB2 (0xF5) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>clk_val</code> (2)
| 7:0
| Upper 8 bits of the calibration offset.
|}

=== CALIB3 (0xF6) ===

{|class="wikitable bittable"
!Name
!Bit
!Description
|-
| <code>???</code>
| 7
| Set to 1 during calibration.
|-
| <code>direction</code>
| 6
|
|-
| Unknown/reserved
| 5:0
| Unknown/reserved.
|}

Template:Hatnote

2025-08-13T13:09:06Z

Knuxify: Created page with "<noinclude><templatedata> { "params": { "1": { "label": "Text", "type": "unbalanced-wikitext", "required": true } }, "description": "Hatnote template, as seen on Wikipedia. Primarily used for \"See also\" text.", "format": "inline" } </templatedata> == Examples == <nowiki>{{Hatnote|This page is about the foo. See also: ''bar'', ''baz''.}}</nowiki> {{Hatnote|This page is about the foo. See also: ''bar'', ''baz''.}} </noinclude><includeonly><div class="..."

<noinclude><templatedata>
{
"params": {
"1": {
"label": "Text",
"type": "unbalanced-wikitext",
"required": true
}
},
"description": "Hatnote template, as seen on Wikipedia. Primarily used for \"See also\" text.",
"format": "inline"
}
</templatedata>
== Examples ==

<nowiki>{{Hatnote|This page is about the foo. See also: ''bar'', ''baz''.}}</nowiki>

{{Hatnote|This page is about the foo. See also: ''bar'', ''baz''.}}
</noinclude><includeonly><div class="hatnote" role="note" style="padding-left: 1.5em; margin-bottom: 0.5em; font-style: italic;">{{{1}}}</div></includeonly>

MediaWiki:Sidebar

2025-06-17T12:00:53Z

Knuxify:

MediaWiki:Sidebar

2025-06-17T11:59:47Z

Knuxify: Created page with " * navigation ** mainpage|mainpage-description ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help-mediawiki * The usual wiki links ** meow * SEARCH * TOOLBOX * LANGUAGES"

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* The usual wiki links
** meow
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Copyrightwarning

2025-05-19T16:13:21Z

Knuxify: Created page with "{{hint|Read the Editor's Guide for wiki rules, information about MediaWiki syntax and other useful hints.}} Please note that all contributions to {{SITENAME}} are considered to be released under the $2 (see $1 for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here. You are also promising us that you wrote this yourself, or copied it from a public domain or similar fr..."

{{hint|Read the [[Help:Wiki editor's guide|Editor's Guide]] for wiki rules, information about MediaWiki syntax and other useful hints.}}

Please note that all contributions to {{SITENAME}} are considered to be released under the $2 (see $1 for details).
If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here. 
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
Do not submit copyrighted work without permission!