On Fri, Mar 9, 2018 at 8:02 PM, Guenter Roeck wrote:
> On 03/09/2018 07:28 PM, Brian Norris wrote:
>> I guess I could mention it. I was assuming that was an intended behavior
>> of the existing driver: that we set resp_mode=0 (via clobber), so we
>> always get a system reset (we don't try to handl
Hi Brian,
On 03/09/2018 07:28 PM, Brian Norris wrote:
Hi,
On Fri, Mar 09, 2018 at 07:20:38PM -0800, Guenter Roeck wrote:
On 03/09/2018 06:44 PM, Brian Norris wrote:
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
of pulse to issue for system reset. We shouldn't clobber
Hi,
On Fri, Mar 09, 2018 at 07:20:38PM -0800, Guenter Roeck wrote:
> On 03/09/2018 06:44 PM, Brian Norris wrote:
> > RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
> > of pulse to issue for system reset. We shouldn't clobber this value,
> > because that might make the syst
Hi Brian,
On 03/09/2018 06:44 PM, Brian Norris wrote:
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
of pulse to issue for system reset. We shouldn't clobber this value,
because that might make the system reset ineffective. On RK3399, we're
seeing that a value of 000b (m
+ linux-rockchip (probably should have included in the first place)
On Fri, Mar 9, 2018 at 6:44 PM, Brian Norris wrote:
> RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
> of pulse to issue for system reset. We shouldn't clobber this value,
> because that might make the sy
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
of pulse to issue for system reset. We shouldn't clobber this value,
because that might make the system reset ineffective. On RK3399, we're
seeing that a value of 000b (meaning 2 cycles) yields an unreliable
(partial?) reset, a
6 matches
Mail list logo