On 13.02.2019 14:40, Vinay Simha B N wrote: > Andrzej/Daniel, > > please suggest any input on the scenario for temperature control and > dsi bridge enable/disable. > > On Mon, Feb 11, 2019 at 2:41 PM Vinay Simha B N <simhavcs@xxxxxxxxx > <mailto:simhavcs@xxxxxxxxx>> wrote: > > dsi2hdmi(adv7511) chip operating temperature range is -10 degC > to +85 degC. We want to enable/disable the bridge only when > temperature range is inbetween these range. > > We have temperature control chip to read the temp, tLow an tHigh > can be set. whenever interrupt(alert) triggers we want to > enablel/disable the bridge. > > Any suggestion what is the better way to handle this scenario? > Why do you need to bother about this quite big range at all? I guess the best would be to set whole platform operating temperature range, and poweroff/sleep/slow down/??? whole system, not just one random chip, which probably is not the most fragile piece, am I right? If you really insist on handling it per chip, you can try to investigate following paths: 1. Just disable the chip, without noticing drm, other drivers, or userspace, and re-enable it if temperature become acceptable, but I am not sure if this will not change behavior of other chips. 2. Disable the chip and report to the drm subsystem connector_status_disconnected - this will cause drm to stop display pipeline and userspace notification. Regards Andrzej > > regards, > vinaysimha > > On Mon, Feb 11, 2019 at 2:10 PM Daniel Vetter <daniel@xxxxxxxx > <mailto:daniel@xxxxxxxx>> wrote: > > On Mon, Feb 11, 2019 at 09:32:54AM +0100, Andrzej Hajda wrote: > > On 11.02.2019 07:52, Vinay Simha B N wrote: > > > hi, > > > > > > is it possible to control the drm bridge from another > driver in irq > > > handler(enable/disable the bridge)? > > > > > > If you mean 'in irq context' the answer is no, usually > enable/disable > > callbacks can sleep, so cannot be called from atomic context. > > > > > > > > > > is there a way to control the "dpms force off" and "dpms > force on" in > > > the interrupt handler? > > > > > > Could you elaborate more on both subjects. > > Yeah, please explain what you want to use this for. dpms on/off is > controlled by userspace, the kernel should not change that > state behind > usersapce's back. If this is for some manuel refresh display, > then that's > a bit a different story ofc, but for that you don't want to do > a real dpms > force off/on. > -Daniel > > > > > > Regards > > > > Andrzej > > > > > > > > > > -- > > > regards, > > > vinaysimha > > > > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > <mailto:dri-devel@xxxxxxxxxxxxxxxxxxxxx> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > <mailto:dri-devel@xxxxxxxxxxxxxxxxxxxxx> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > > > > -- > regards, > vinaysimha > > > > -- > regards, > vinaysimha _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
