adomerle has quit [Quit: Client limit exceeded: 20000]
AffeNull[m] has quit [Quit: Client limit exceeded: 20000]
alfayt[m] has quit [Quit: Client limit exceeded: 20000]
alikateshethey[m] has quit []
ArianK16a[m] has quit [Quit: Client limit exceeded: 20000]
blacksilver[m] has quit [Quit: Client limit exceeded: 20000]
bzy-080408[m] has quit [Quit: Client limit exceeded: 20000]
Leandro[m]12 has quit [Quit: Client limit exceeded: 20000]
Degdag_Med[m] has quit [Quit: Client limit exceeded: 20000]
dehirt5212[m] has quit [Quit: Client limit exceeded: 20000]
danylo1 has quit []
elektrino[m] has quit [Quit: Client limit exceeded: 20000]
felixwither[m] has quit [Quit: Client limit exceeded: 20000]
FieryFlames[m] has quit [Quit: Client limit exceeded: 20000]
Adrian[m] has quit [Quit: Client limit exceeded: 20000]
Guest10980 has quit []
jrole_8tst-j[m] has quit []
JoelSelvaraj[m] has quit [Quit: Client limit exceeded: 20000]
jrfern[m] has quit [Quit: Client limit exceeded: 20000]
luka177[m] has quit [Quit: Client limit exceeded: 20000]
Steve[m]123 has quit [Quit: Client limit exceeded: 20000]
maxim[m] has quit [Quit: Client limit exceeded: 20000]
minecrell[m] has quit [Quit: Client limit exceeded: 20000]
MollySophia[m] has quit [Quit: Client limit exceeded: 20000]
mothenjoyer69 has quit [Quit: Client limit exceeded: 20000]
nick1343[m] has quit []
panioluka[m] has quit [Quit: Client limit exceeded: 20000]
Prawn[m] has quit [Quit: Client limit exceeded: 20000]
Nia[m] has quit [Quit: Client limit exceeded: 20000]
sepkov[m] has quit [Quit: Client limit exceeded: 20000]
TJ[m] has quit [Quit: Client limit exceeded: 20000]
uclydde[m] has quit [Quit: Client limit exceeded: 20000]
wfranken[m] has quit [Quit: Client limit exceeded: 20000]
xtex[m] has quit [Quit: Client limit exceeded: 20000]
ywnkmn[m] has quit [Quit: Client limit exceeded: 20000]
RayyanAnsari[m] has quit [Quit: Client limit exceeded: 20000]
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
phh has quit [Remote host closed the connection]
phh has joined #linux-msm
pespin has joined #linux-msm
mripard has joined #linux-msm
socksinspace has quit [Quit: WeeChat 3.8]
socksinspace has joined #linux-msm
nta has quit [Quit: Client limit exceeded: 20000]
srinik has joined #linux-msm
<z3ntu>
<konradybcio> "Don't you have a fp5?" <- Define audioreach then? That's q6apm+q6prm?
<konradybcio>
I.. think so?
<z3ntu>
konradybcio: I'm 100% sure that at least to some degree q6afe+q6asm+q6adm ("pre-audioreach"?) is functional on my firmware since I've validated DisplayPort Audio and also to some extent speaker using that
<z3ntu>
my firmware = QCM6490 LA
<marc|gonzalez>
krzk: lumag: thank you for your guidance on the TDP158 binding. I'm not an electronics engineer, I talked to one at work. The documentation states that the device can be configured by I2C or by pin strap. As far as I understand, if by pin strap, then an I2C bus is not necessary, as the config is static. What do you think?
<lumag>
marc|gonzalez, according to the schematics, is TDP158 connected to the i2c bus? If it is, then please describe it as an i2c client
<marc|gonzalez>
lumag: I meant for the binding. It is not supposed to describe just my implementation? (that's what I thought)
<lumag>
marc|gonzalez, that's what I'm asking for: is it connected to the bus?
<marc|gonzalez>
I mean: if another vendor uses the TDP158 in pin strap mode, they will have to make a separate binding & driver?
<lumag>
maybe yes, maybe no.
<marc|gonzalez>
lumag: on our box, the device is connected on an i2c bus, yes. But it is not mandatory
<lumag>
marc|gonzalez, it is connected to an i2c bus => from the bindings POV it is an i2c bus client
<lumag>
bindings and DT describe hardware connections.
<marc|gonzalez>
We are not understanding each other
<marc|gonzalez>
You and krzk wrote that "reg" should be marked as "required". But the device is allowed to be connected outside of an i2c bus, so with no reg to speak of.
<marc|gonzalez>
I agree that I should use a reg for my board
<marc|gonzalez>
But I had doubts that it should be forced for everyone
<marc|gonzalez>
Then again, the driver is an i2c_client driver, so I guess it makes sense to say "reg is required"
<lumag>
marc|gonzalez, there was no 'driver' in the DT bindings discussion
<lumag>
I'd say, define just i2c bindings and when somebody needs to implement anything else, it will be the next patch.
<marc|gonzalez>
OK that makes sense.
<z3ntu>
I think if a device can operate in i2c or gpio mode (or potentially any other mode) then we need separate compatibles and separate kernel drivers? I've had the case also for I think the typec redriver I made a driver for, I opted to just ignore the gpio mode since I cannot test it anyways since on my hardware it's controlled via i2c
<lumag>
z3ntu, compatibles describe the hardware. It's the same hw, so it can use the same compat string
<z3ntu>
lumag: Can you register the same compatible as both i2c_driver and platform_driver?
<lumag>
Yes, why not?
<z3ntu>
idk, I guess I don't know in detail how device probing works with matching compatibles
<marc|gonzalez>
I have no idea how to address mripard 's remarks
<marc|gonzalez>
I don't know where to start
<marc|gonzalez>
let's take pin 8, I2C_EN (an Input). On our board it's set to 1 by a pull-up according to the HW engineer
<marc|gonzalez>
Should I declare as a GPIO that is always 1?
<marc|gonzalez>
Are we supposed to describe all the I signals in the binding?
<bamse>
marc|gonzalez: the yaml should describe the various aspects of how the component is integrated on your board - such that an implemmentation could be written to support any (most) such variations
<bamse>
marc|gonzalez: for I2C_EN that would imply adding a i2c-en-gpios = <> property, which i presume should be an optional property
<marc|gonzalez>
So you're saying all input signals should be described in the YAML?
<marc|gonzalez>
I mean, all control signals
<bamse>
marc|gonzalez: so add it in yaml, probably ignore it in implementation (for now?) and omit it in the dts
<marc|gonzalez>
On my board, the value is hard coded to 1 by a pull-up
<marc|gonzalez>
It was considered to have a GPIO, but it didn't materialize
<bamse>
yeah, that's what Maxime is asking you to do (and it's a reasonable ask)
<bamse>
sounds like a very typical design, i'm seeing a lot of those
<marc|gonzalez>
you guys who do this day in and day out kinda forget what it's like to never have done it...
<bamse>
i think you'd find plenty of prior art where such pins are not described, but it's not an unreasonable ask
<marc|gonzalez>
This pin makes sense I guess
<marc|gonzalez>
I don't understand the other stuff, it's over my head
<bamse>
the dvi/hdmi/dp remark?
<marc|gonzalez>
Yeah
<marc|gonzalez>
and how to address it, more prosaicly
<bamse>
i'm not sure how that would impact your binding...
<marc|gonzalez>
If you don't know, I'm in limbo.
<marc|gonzalez>
The original quick and dirty patch was 4 quick and dirty lines.
<bamse>
lane swapping is done in a bunch of other bindings, by the data-lanes property
<marc|gonzalez>
I thought I could get away with a minimal driver
<bamse>
regarding dvi/hdmi/dp, by your knowledge of the chip, how would that impact the description of how the chip is connected?
<marc|gonzalez>
It doesn't change how the chip is connected, it might change how it is configured though
<marc|gonzalez>
Like slew & these low level signal settings
<bamse>
but that sounds like an implementation detail? or does those properties need to be described per board?
<marc|gonzalez>
I guess one might need to say "this device expects DVI in" or "this device expects HDMI in" ?
<bamse>
can't we derrive that from just query what's on port@0?
<marc|gonzalez>
Perhaps...
<marc|gonzalez>
But even the I2C_EN sounds weird to me
<marc|gonzalez>
I wrote an i2c_driver. It doesn't make sense if I2C_EN = 0
<marc|gonzalez>
I guess this is what was discussed earlier by lumag & z3ntu. Can a binding be implemented by 2 separate drivers?
<marc|gonzalez>
So I2C_EN = 1 means my driver. I2C_EN = 0 means another driver
<marc|gonzalez>
(Actually, if everything is statically configured in HW, there's nothing for a driver to do)
<marc|gonzalez>
except maybe toggle the Operation Enable pin, which is what my driver is doing
<marc|gonzalez>
I should maybe just code a platform driver, and cut the little I2C_EN trace on my board
<bamse>
it would have to be two separate drivers
<bamse>
because in the i2c_en = 0 case your device doesn't sit on a i2c bus and hence it can't be a i2c_driver, but must be a platform_driver
<marc|gonzalez>
that makes sense
<bamse>
i mean, you can probably squeeze both into the same c-file if you really want to...but in the i2c_en=0 case, what interaction do you have with the component?
<marc|gonzalez>
GPIO for Operation Enable, that's it
<marc|gonzalez>
for power saving
<marc|gonzalez>
We should have just used a pull up for OE, and no driver would have been required
<bamse>
i've not read the datasheet for this thing, but would it be reasonable to have a design where the driver will let that go low at times?
<bamse>
sorry, read that again
<bamse>
so, all the driver would do is driving that gpio high/low? and then we'd perhaps want the ports to be able to describe the drm pipeline accurately?
<marc|gonzalez>
precisely
<marc|gonzalez>
Patch v0 was simply declaring the device as a simple bridge
<bamse>
i guess you could have a single yaml with the same compatible describing the two cases, and then two separate implementations depending on the node being expressed on the platform bus or an i2c bus
<bamse>
lumag: you have some ideas regarding this, what do you say?
<marc|gonzalez>
I'm trying to do less work, but you're suggesting more ;)
<marc|gonzalez>
Keep in mind this component is 8 years old, and probably no one uses it at this point, and no one will
<bamse>
marc|gonzalez: well, only sort of...i'm suggesting that you propose a binding that covers both cases, but you only implement the case you need in linux
<krzk>
but please do not come up with some fake non-i2c binding just to satisfy theoretical needs... I think I was clear - if you can put it in some other place and it would be a valid setup, then reg is optional, because reg is defined by the bus.
<krzk>
anyway it is really not worth such discussions
<bamse>
krzk: are you saying "ignore the non-i2c case...and consider the non-i2c case"?
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<bamse>
krzk: i find it perfectly reasonable to let marc describe the i2c-case for now, as it's not clear to me how the other configuration (where linux doens't have a way to talk to the chip) would be expressed
asriel has joined #linux-msm
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #linux-msm
mripard has quit [Quit: mripard]
<krzk>
bamse: I said that doing non-i2c case, just fo rthe sake of completeness or satisfying comments, is rather waste of time. But if you want to waste time, I provide the guideline, so answer the question: can it be put anywhere in the DTS and be correct?
<bamse>
krzk: okay, i'm totally onboard on the first part...and i think it's rather clear that marc doesn't not want to waste the time to come up with something like that
<marc|gonzalez>
understood
<DylanVanAssche>
srinikI have been trying to get a 2nd SLIMBus Controller up on SDM845 for the WCN3990 module. I get a few errors which do not happen with the SLIMBus Controller for the WCD9340 codec. Do you know what these mean?